你所看到的所有分离 handle 操作本质上都和这个 issue 有关
https://github.com/golang/go/issues/19098
net 库中正常的 Read 和 Write 以及 ReadFrom/WriteTo 接口实际上都进入了 internal/poll 中使用 execIO 函数调用 iocp 完成，并不会封装成*os.File

@seWindows 正常的 Read 和 Write 调用根本不会走到那个 dup 的
如果你的说的是两个*net.TCPConn 直接 io.Copy 拷贝的速度，那单纯就是 Linux 下会调用 splice 而 windows 下没这项优化

哪怕是用 md5 对于代码签名来说，想伪造一个既能正常运行，还能达到你目的，同时 hash 结果不变的代码，目前也没有成熟的攻击方法吧

@w568w "摆弄 net 和 libc 的链接问题"，请直接设置 CGO_ENABLE=0 ，之后就不需要摆弄了

@HFX3389 #65 自然是对着 golang 仓库一个 commit 一个 commit 翻找相关的，然后撤回后在 win7 上实验能不能正常运行喽

@lysShub #70 我在代码中也留了注释，这种撤回方法还是需要对特定版本进行适配的，不过从我这边的 github action 来看，直到最新的 golang1.21.11 和 1.22.4 上工作都是正常的
至于为什么 action 中 1.21 系列是直接从 golang 官方仓库取 diff ，而 1.22 自己放了一份 patch 文件就是因为 1.22 的修改需要额外修改一些对应行数才能正常撤回
如果想应用到未来发布的 1.23 那肯定还是要重新写 patch 的

@cheneydog #34 其实只是精简掉了旧的兼容 win7 支持的代码而已，毕竟微软都宣布 EOL 了，golang 官方也没有足够的精力维持兼容性

还有一些比较麻烦的方法，比如手动分叉一些需要高版本 golang 的依赖，恢复对旧版的支持
https://github.com/MetaCubeX/randv2
https://github.com/MetaCubeX/quic-go/tree/v0.45.0-mod-meta
https://github.com/MetaCubeX/gvisor/tree/meta-20240320-6368c171a198
当然这种做法有点费力不讨好

如果是 golang1.22 那需要撤销的是三个 commit
https://github.com/golang/go/commit/693def151adff1af707d82d28f55dba81ceb08e1
https://github.com/golang/go/commit/7c1157f9544922e96945196b47b95664b1e39108
https://github.com/golang/go/commit/48042aa09c2f878c4faa576948b07fe625c4707a
如果需要对 KB2533623 之前的版本做兼容，一样需要撤回
https://github.com/golang/go/commit/a17d959debdb04cd550016a3501dd09d50cd62e7

我选择在编译的时候给 golang 打 patch ，对于 golang1.21 撤销掉一个 commit 即可恢复对 win7 的支持
https://github.com/golang/go/commit/9e43850a3298a9b8b1162ba0033d4c53f8637571
如果需要对 win7 打 KB2533623 之前的版本做兼容，那就再撤回一个 commit
https://github.com/golang/go/commit/a17d959debdb04cd550016a3501dd09d50cd62e7

@Seves 找到原因了
https://github.com/golang/go/commit/a17d959debdb04cd550016a3501dd09d50cd62e7
根据 msdn 文档：
Windows 7 、Windows Server 2008 R2 、Windows Vista 和 Windows Server 2008：LOAD_LIBRARY_SEARCH_标志在安装了 KB2533623 的系统上可用。 若要确定标志是否可用，请使用 GetProcAddress 获取 AddDllDirectory 、RemoveDllDirectory 或 SetDefaultDllDirectories 函数的地址。 如果 GetProcAddress 成功，LOAD_LIBRARY_SEARCH_ 标志可以与 LoadLibraryEx 一起使用。
所以在缺乏补丁的 win7 上就会出现找不到系统 dll 的问题

@Seves #44 我再次重新安装了一次 win7 ，在没有安装 kb4474419 的时候出现了和你一样的报错，安装后即可正常启动了
https://www.catalog.update.microsoft.com/search.aspx?q=kb4474419
实际上很多非 golang 程序的安装也必须要建立在安装 kb4474419 之后（如 vmtools ），具体原因还需要探究

@Seves 你这个报错感觉是系统有很多补丁没打吧，能看一下你系统上 C:\Windows\System32\advapi32.dll 的详细信息么

@Seves #38 我手动装了一下 win7 32 位版本的系统，和你的版本一样也是 7601 ，但是我安装了 kb4474419 ，之后运行 golang1.21 版本编译出来的文件一切正常，你也可以测试一下我 patch 后的 1.22 编译出来的二进制兼容性如何
https://github.com/MetaCubeX/mihomo/releases/download/v1.18.5/mihomo-windows-386-v1.18.5.zip

@Seves 这么说也确实没问题，我这边的实测是 1.21.3 编译出来的 386/amd64 产物均可以在 win7 64bit 下正常运行，去除#34 提到的指定 commit 的 go1.21 和 go1.22 也都可以在 win7 64bit 下正常运行
至于 32 位系统下为何不行，但是在 64 位系统下 wow64 可以的问题我没有深入测试过，能找到的资料也非常有限，一直没人深究到底是哪个 commit 的改动引发了这个不兼容

@Seves 你这个问题应该是系统内存不够导致的，高版本 golang 需要更大的虚拟内存空间，我这边只测试了在 win7 的 64bit 下是可以正常工作的

翻阅了一下相关 commit ，@Seves 提到的包减小了是因为
https://go-review.googlesource.com/c/go/+/475378
这个提交将 pkg/tool 中二进制文件的 debug info 信息删除所以才减小了那么多，和移除了对旧系统的支持无关

对于 go1.21 来说，影响 win7 兼容性的 commit 只有一个
https://github.com/golang/go/commit/9e43850a3298a9b8b1162ba0033d4c53f8637571
对于 go1.22 来说，也就只有三个
https://github.com/golang/go/commit/693def151adff1af707d82d28f55dba81ceb08e1
https://github.com/golang/go/commit/7c1157f9544922e96945196b47b95664b1e39108
https://github.com/golang/go/commit/48042aa09c2f878c4faa576948b07fe625c4707a
然而这些 commit 都不可能导致包大小有 30m 的变动，当你手动 revert 这些 commit 后可以在 win7 上正常运行，同时也不会增加编译出的文件大小

@Seves 其实并没有什么关系，事实上直到 go1.21.3 还是能在 win7 上正常运行的，只是 1.21.4 调用了一个新的 win32 api 后才导致无法启动的