@sddyzm 问题是处理起来就没法一样，需要新 header 、各种设备需要大改，要不然根本没法用

而且地址空间比 IPv6 小一半，这可就算不上什么优化了，3L 和 8L 也提到过

@sddyzm 这种改法也就易于人类理解，兼容性一样只利于人类兼容
对于二进制世界而言，实际上是做不到兼容的（我在第三部份已经举例了）

UDP 测速可以试试 http3 ，不一定要用 iperf

补充：最后一行还有个 8K 编码，但只有 AV1 这个编码类型

571 mp4 7680x4320 60 │ 1.04GiB 27064k https │ av01.0.17M.08 27064k video only 4320p60, mp4_dash

文件大小接近于前面 4K VP9 ，仅仅是大几十 MiB

漏了一个更重要的参数：编码格式

单论 youtube ，这个平台支持 H264 、AV1 和 VP9 ，对于 2.5K 、4K 及更高分辨率的视频并不使用 H264 ，只会使用 AV1 和 VP9 。

就以这个视频为例：

https://www.youtube.com/watch?v=G5RpJwCJDqc

使用命令行查看编码和码率
yt-dlp -F "https://www.youtube.com/ watch?v=G5RpJwCJDqc"
（ URL 中的空格自行去掉）

最后 4 行是这样的：

308 webm 2560x1440 60 │ 424.59MiB 10798k https │ vp9 10798k video only 1440p60, webm_dash
400 mp4 2560x1440 60 │ 242.05MiB 6156k https │ av01.0.12M.08 6156k video only 1440p60, mp4_dash
315 webm 3840x2160 60 │ 965.87MiB 24564k https │ vp9 24564k video only 2160p60, webm_dash
401 mp4 3840x2160 60 │ 496.68MiB 12631k https │ av01.0.13M.08 12631k video only 2160p60, mp4_dash

可见 VP9 的码率、文件大小都比 AV1 的高得多，接近乘 2 了

Transmission 的 preallocation 要自己手动改 settings.json

https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md

如果 GUI 有相应选项，要看清楚选项内容，因为 Transmission 的预分配模式有 3 个（关闭、快速、完整）。

不用 qBittorrent 的话，还可以选择 Transmission

应该是旧版 qbittorrent 的 bug ，早在 2023 年就有人在 GitHub 提了 issue:
https://github.com/qbittorrent/qBittorrent/issues/19410

具体可以看一看“HDD + LINUX + NTFS + NO-PREALLOCATE”以及“HDD + LINUX + NTFS + DO-PREALLOCATE”的部分，以及后面那一两层楼。

原作者的描述是，在 Linux 环境无论是否选择预分配，qbittorrent 都会预分配。

按照这个 issue 底部的 comment ，升级到 qBittorrent 5.0.4 应该就行。

2038 问题由工具链兜底实在是强人所难了，毕竟作用很有限。即使工具链给了 64 位 time_t 在内部做转换，到了 OS 层面给出的时间直接就是错的，工具链再怎么兜底都没用。这就好比寄信人提供的门牌号直接就是错的，就算印门牌号的纸足够容纳都没用。

MinGW 那边可以认为是没人搞，长期以来进度缓慢，无解

这个有折中做法，chcp 65001 即可解决。也可以主动调用 SetConsoleCP 和 SetConsoleOutputCP 。

Android 的事情，老实说，那得看 Google 的脸色了。编译器开发者或许能够解决二进制文件生成的支持，但 SDK 的更新就无能为力了。若 Google 决定停止向旧版系统提供新版 SDK （无论 C/C++还是 Java/Kotlin ），无论给多少钱都不行，那也不可能拿起武器对准 Google 大楼要求他们继续更新的吧。这个责任，不是某一个编程语言能够承担的。除了 Google 自己，其他人拿它没办法。顶多只能靠开源社区自己打 patch 做更新。
打个比方，这就相当于要求在 Linux 4.x 使用 io_uring 的 API ，编译时发现不存在然后责怪编程语言和工具链，属于怪错对象了。想要用不是不行，这得有人愿意做 backport ，但这显然不是编程语言和工具链的责任了。

多说一句，如果换了“其他语言”写程序手动调用 POSIX API ，照样会遇到一模一样的情况
手动调用 Win32 API 同理（例如 rust winrt ）

这是 C 的事情，发到 C++板块不怎么妥当吧

前半部分

1 ，这是 MSYS MinGW 的锅，它们没处理好 64 位的适配。Windows 提供了 fseeko64 的替代品 _fseeki64()，中间转换层本该做好映射支持的。
2~6 ，这就是系统 API / SDK 的锅，包括 Android

至于换语言能“解决”这些锅，本质上只是它们在标准库里面帮忙擦屁股而已。


「为什么开发环境就不能默认支持这些情况呢，难道还影响兼容性？」

开发环境当然可以默认支持这些情况，正常 POSIX 环境、正常 MSVC 环境直接写程序调用标准库 API 都没问题。
没做到默认支持，很多时候完全是疏忽 (MSYS MinGW)，或者是怕麻烦、赶进度(Android 5.0~6.0)。


后半部分

1 、若是 OS Level 的限制，编程语言本身能做的事情其实很有限。如果 OS 本身没解决 2038 问题，只要系统关机、重新开机，系统时间直接就是乱的，再完善的编程语言都没办法强行掰回来。
若 OS Level 已经解决了 2038 问题，那么无论是 C 还是 C++，都不需要担心这种事。

2 、纯 POSIX 可以。跨平台跨到 MSYS MinGW 的话，按理说 MSYS MinGW 应当处理好相应转换（像是背后处理编码调用带 W 的 API 、检测目标 Windows 有没有启用 UTF-8 区域选项），但这就不是普通使用者可以强制要求的了。

3 、这就有点霸道了，别说 C 语言、C++，哪怕是 Python 都没法如此保证。

4 、单纯“不拒绝使用”的话，那还是不需要担心。如果想要更高要求达到“表现一致”，那就不太可能了。
Linux 的 IPV6_V6ONLY 默认为 false ，而 BSD 和 macOS 还有 Windows 的 IPV6_V6ONLY 默认是 true 。
OpenBSD 更是搞起了内部限制，无论 IPV6_V6ONLY 设成什么值，它都按照 true 处理。

5 、类似 2

6 、支持近十年出厂的系统很合理。但硬件？？这可不是编程语言可以掌控的吧，这是 OS 和驱动程序的责任啊。

自己建一个落地机，然后在落地机连接上大品牌的商业 VPN ，让梯子流量从这条 VPN 链路出去

那就试下创建多个本地账户，然后使用 run-as （ Shift+鼠标右键，运行为）

多线程读写的话，能用 atomic 就尽量用，C 语言也有内置的（记得是从 C11 开始的）

如果一定要在工作时间，那么建议在自家设备（例如 NAS ）设立私家 git 仓库（位于不同文件夹），工作时间的代码修改一律推送到这个私家仓库，不要推送到 GitHub 上面（务必记住）。
下班回家后，把改好的代码转移到 GitHub 的本地 clone 文件夹，再推送给 GitHub 。

这样做有两个好处：
1 、时间戳一定是下班后的，没有把柄被人针对（前提是，上班时没被当场逮住）
2 、GitHub 上面的代码更改是当日的汇总，没人知道你中途用了多少时间

虽然用一个仓库也能做到，但万一疏忽手误就可能直接推送给 GitHub 了
分成两个仓库、不同文件夹可以彻底避免发生这种事