@gongym 兼容说是兼容，可这不是理想情况吗。

按照 Hyrum’s Law ，实际上你已经依赖了 Go 内部的非公开实现，而你永远不知道你的同事和你依赖的库有什么骚操作。这样的例子其实有很多：
1. 依赖反射和 unsafe ，这些库不保证行为兼容。unsafe 就不说了。reflect 更隐蔽，比如`reflect.DeepEqual` 的行为变过。你用高版本的 Go 去编译老版本不带修复的 K8s ，你会发现一堆 CR 提交不上去。
2. 依赖黑魔法注解，一堆库被 rcs 在 Go 源码里拉耻辱柱群，这些库多半你用过：containerd 、protobuf 、sonic ；有一些改了退群了，有一些一直还在。
3. 你依赖了 golang.org/x 下面的库，这玩意的版本很玄学，兼容性就更别说了。

现在 golang 高版本的 gomod 里可以申明 toolchain 版本。

当然，我现在参与的项目的版本还不支持这个功能。升级是不可能升级的，这辈子都不可能升级的。

是不是因为 CloudFlare 的原因

Youtube, Infuse, Netflix

按文件系统拷贝，linux 下面 umount 了之后直接 dd 整个块设备到新硬盘。类似`dd if=/dev/sda of=/dev/sdb`。另外新设备要比老设备大，否则你得先缩文件系统。

按文件拷贝多线程也没用，瓶颈都在 io 上。

您是在注入文件夹嘛？

1.「单位时间」是多大的单位，出门玩一趟的照片同步到 B2/S3 一波就直接炸了；
2. DNS 可还行，用私有 DNS 运营商缓存失效了就封号是吧？

其实公司组织架构、社会体制才是对人的编程。设计规则，让一个个人在规则里流转。

@Qpasserby 其实不是因为要进去，是因为市场太小众了。esim 现阶段也只是小圈子里比较关心而已，大部分人都不太关心这个。退一步说，抓人也看 ROI 的，性价比太低了。其实早些年也有写号和玩卡的人，懒得管而已。

P 的点在于是否允许出现分区，A 是系统的可用性。 因为一般只有 CP 或者 AP ，不太可能会设计 CA 系统，所以 P 似乎是一个前提了。即在 P 这个前提下，A 和 C 之间做 Trade off 。

其实 CAP 里的 C 、A 、P 都不是绝对的，C 里面也有很多不一样的一致性程度。 一般讲的时候只是设计上更偏向于 CP 还是 AP 。不是说 AP 系统就允许不一致，CP 系统就完全不可用。

另外我反而是好奇 Android 阵营，因为限制下载境外 Esim 似乎是系统做的限制，IOS 也要下载了一张境内 esim 之后才回 disable 掉境外 esim 的下载功能。 那么，在 Android 阵营的第三方 ROM 是否可以解开这个限制？

@someonesnone 现在有传言国内版本只能下载两个 esim profile 。 如果你在国内已经双卡了，出国旅游落地境外之后，你要先删掉一张国内的 profile 才能下载其他境外的 esim 。 而下载境内三大运营商的 esim 办理又要去营业厅，那意味着你回国之后还得把经外的 esim 删掉之后跑一趟营业厅。

「事到如今，我最对不起的就是家人」

其实能的，大部分产品在出现扩展性问题之前就已经死了。后面如果不幸真成了，还可以招人来屎上雕花。

@renfei 启动韭菜保护程序

一个月用不到 50 的是不是就没必要了，交通联合或者银联就行了。

我妈喜欢用「电捂煲」，放里面自己慢慢突突一晚上。