感谢各位回复！
我刚才发现在完全不使用原始的 加载.mp4 的情况下依然会出现这个问题，可能是我的思考方向错了，今天被这个问题心态搞得有点绷不住。。。
目前初步怀疑是最后一步 concat 之前会把一个大视频拆分成前后两段，后面那段 trim 之后没加 setpts 导致的（因为前面一段正好是 7s ，让我误以为是原始视频的 7s ）
有后续进展再更新

@msg7086 初学视频编辑，还不知道你说的这些名词啥意思...但最后 concat 那一步我对齐了分辨率都是 1920x1080 ，帧率都是 60 fps ，还有啥需要注意的吗

@lovelylain ffprobe -loglevel trace "加载.mp4" 贴到这里了： https://gist.github.com/henix/0ae8a97aeb78fc60206e4b75464fcfbd
这个原始视频是别人给我的，估计应该是用 Adobe 的软件做出来的

参考微信读书、豆瓣阅读的那种黄色背景

sqlc

似乎你把 RSS 理解为内容农场站一类的东西了。如果是像内容农场一样只是抓取别人的东西来当做自己的内容，那确实可以说是盗版。

但你可以去了解一下原始的 RSS 阅读器（推荐这篇文章 https://sspai.com/post/56391 ）而不是最近的 Follow 。最初的 RSS 阅读器是在电脑上安装的一个客户端。

我认为 RSS 阅读器就是一种特殊的自带“阅读模式”的浏览器。我可以用普通浏览器去看，也可以用浏览器提供的“阅读模式”去看，也可以用 RSS 阅读器去看。

如果我喜欢这个内容，我自然会跳转回原站点赞收藏。

换一个理解方式：现在很多笔记软件都提供“网页剪藏”，将一个网页剪藏到笔记中，还可以去掉页面上无关部分。RSS 阅读器相当于对我关注的作者，每出来一篇新文章就自动帮我剪藏了。我认为这不算盗版。因为作为用户，我有权决定如何处理这些我消费的内容。

这个问题继续讨论下去就是：你认为我们更应该维护读者还是作者的利益？比如现在很多浏览器可以安装“去广告”插件，也许原作者希望你看广告，按你的逻辑，这更是对原作者利益的直接侵犯。但读者有时候也深受广告之苦，所以又有人开发了“李跳跳”之类的跳过广告应用。

CLCL

TS 相对于 js 多加了很多东西，为的是大型工程中多人协作更可维护，js 更基础，所以先学 js 。
要开发一个网站不只需要学 js ，还有 HTML / CSS 这些，可以看看 https://csdiy.wiki/ 的 Web 开发 部分

协作就是双方约定好一个接口 / 规范 / 协议，规定了数据如何传输，以及这些数据的含义。类比的话就是现在的 USB / 蓝牙之类的接口，如果主机和设备都支持了这些接口就可以通信。
Web 开发中的前后端，底层是通过网络协议通信，具体来讲，最底层是 TCP ，然后是 HTTP ，然后是应用自己约定的协议。

最简单的直接用环境变量
没有复杂嵌套的用 ini
复杂的用 json5 或 json
不推荐 yaml ，这玩意一旦规模上去之后，可读性大幅下降。而且 spec 相当复杂，不同语言实现出来的 yaml parser 可能有功能上的差异，导致同一个配置文件，无法在不同语言之间迁移

默认的 Go 插件，在代码里用到啥就会导入啥啊，在下面的代码里直接写 rand ，然后一个“.” 然后要调用的函数名，自动给你补上 import

我也觉得，心智负担低到甚至可以用记事本一遍写出可以通过编译的代码

展示加载进度条

感觉你对 https 证书有一些误解。
“利用这个公钥去做加密，将加密的内容写在这个应用的配置文件里，再在程序启动的时候利用 keystore 去解密”
这个说法没错，但能这么做的前提是，这个程序正好是一个 https 网站的服务端

服务器的 keystore 保存了只有服务器才有的私钥和公钥，进行 https 连接握手时，客户端连接到服务端，服务端会先把自己的公钥发给客户端，然后客户端用这个公钥进行加密操作。所以客户端的 keystore 不需要保存任何私钥

个人感觉一些国外大佬博客评论区交流氛围挺不错，真的在讨论技术，比如：
https://preshing.com/
https://ericniebler.com/
https://maskray.me/blog/ （这位是是国人）

在那台机器上加个监控，看看监控数据：CPU / 内存 / 磁盘 IO 等等
说不定是其他人在那台机器上跑定时任务呢

AES 的 CTR 模式，通过加密一个不断增长的计数器来得到一个密钥流（ key stream ），我认为这就相当于一个伪随机数生成器 https://zh.wikipedia.org/wiki/%E5%88%86%E7%BB%84%E5%AF%86%E7%A0%81%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F#%E8%AE%A1%E6%95%B0%E5%99%A8%E6%A8%A1%E5%BC%8F%EF%BC%88CTR%EF%BC%89

之前看到的一个知乎回答： https://www.zhihu.com/question/653896828/answer/3480752444
> 简单来说游戏服务器这种架构设计就是为了低延迟而牺牲服务可用性。而这个业务的特性决定了这么做是可行（甚至是必须的）。
我的理解是游戏服务器更重视低延迟，而不太需要高可用。可用性低一点没关系，发补偿就行，玩家也不是随时都在玩（高峰集中在晚上和周末）。
互联网产品更重视高可用，为了可用性可以牺牲延迟。

FBReader