cnbatch

这是 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+鼠标右键，运行为）

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

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

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

而且 Windows 11 远不止 UI Bug ，任务栏随意放置的功能都还没弄回来，还有各种底层功能错乱（前几天就有一个 /t/1178718 ），这么拖下去遥遥无期了呢