Build: Use patched newer Go version to build Windows 7 assets

[KobeArthurScofield]

见 #4192 (comment)

该 pr 包含移除使用 Go 1.21.4 编译 win7 版本的更改，应用该 pr 后，自动构建过程不会再产生 win7-32 及 win7-64 两组二进制。同时在 Github Actions 中构建时使用的 Go 版本取决于 go.mod （和之前一致）。

该 pr 并非 #3530 的完全还原，patch-assetname 暂时被保留（可用于其它用途）。

建议仅在决定移除使用 Go 1.21.4 提供对 Windows 7 的支持时合并

如果计划用打了 win7 支持补丁的 Go 在 Actions 进行编译，大概需要：一个经过修改的 Go 库，一个修改过的 setup-go，以及单独准备的 actions 文件。说不定会出现在 actions 里面先 build go 再用 build 出来的 go 编译特殊版本的事

[KobeArthurScofield]

#4195 移至此处

现在通过在 Actions 中先使用现有 Go 编译打了兼容补丁的 Go 后，使用补丁后的 Go 编译出也许能在 Windows 7 上用的二进制。目前处于能构建并且构建出来的二进制的确能运行的阶段，但是手边没有安装了 win7 的机器或者镜像所以只能找小白鼠了。

目前使用 MetaCubeX/go 作为改版 Go 的来源，可以修改为其它仓库。

因为构建耗时较长，触发器相比一般的 build 少了对出现 go 文件发生更改时的触发项。

技术有限，目前编译出来的二进制不会显示 commit SHA。 更新：显示长 SHA。

[KobeArthurScofield]

弄了个虚拟机看看，能运行，不知道会不会有什么问题。没有实机，已经坏掉很久了。

Windows 7 Professional x64，没有安装 SHA2 代码签名更新。

应该跟之前一样保持只编译，不保证其它支持？

[KobeArthurScofield]

更新：此 pr 现在采用先编译 Go 工具链再用编译后的工具链编译二进制的方式使在使用新 Go 的情况下支持 Windows 7.

优点是稳定不易受 Go 小版本变更带来的问题

缺点是耗时长且有可能会引发版本控制系统记录问题导致 dirty build，可重现构建有可能受影响。（不影响其它正常的构建）。

如果自己维护一个分支也可以进行切换。

使用此 pr 即可关闭 #4195

[RPRX]

这是自动 patch 吗，要不你开个仓库自动发布对新版 Go 的 patch，然后 Xray 直接拿来用，拉你进组织了

[Fangliding]

https://github.com/MetaCubeX/mihomo/blob/Alpha/.github/workflows/build.yml

[KobeArthurScofield]

这是自动 patch 吗

4192 是直接将整个源代码仓库连带相关的 patch 拉取下来（已经 patch 过），4195 是拉取对应的 patch 贴到工具链里面（Meta 的做法）。

不过要提前手动在对应的源码仓库分支里面放置补丁

[KobeArthurScofield]

要不你开个仓库自动发布对新版 Go 的 patch

可以 （虽然实际干的事可能和隔壁差不多）

最后 4192 和 4195 选一个认为比较合理的 pr 再在上面改改就好，都包含了对 1.21.4 的清理替换

[RPRX]

我觉得从对人类最有益的角度看，应当开个新仓库自动发布 patch 后的新版 Go，然后 Xray 这里直接拿 latest 来用

[RPRX]

比如 Go 发布了 1.23.4，那个仓库就用 1.23.4 自动编译并发布 patch 后的 1.23.4

[KobeArthurScofield]

看来迟早还得把 setup-go 也叉过来 patch 了

[RPRX]

比如 Go 发布了 1.23.4，那个仓库就用 1.23.4 自动编译并发布 patch 后的 1.23.4

@KobeArthurScofield 有空时按这个实现一下吧

[crazypeace]

我觉得从对人类最有益的角度看，应当开个新仓库自动发布 patch 后的新版 Go，然后 Xray 这里直接拿 latest 来用

我觉得 xray 就在发布的时候从那个仓库拿编译后的执行文件就好。

[KobeArthurScofield]

有空时按这个实现一下吧

可以，短期内先用将 patch 打进工具链来迁移最低支持 Go 版本，这个完成后应该可以迁移过来。

我觉得 xray 就在发布的时候从那个仓库拿编译后的执行文件就好。

是用 setup-go 的方法塞进去还是直接塞到 GOROOT 这个不知道要不要考虑一下

[RPRX]

可以，短期内先用将 patch 打进工具链来迁移最低支持 Go 版本，这个完成后应该可以迁移过来。

我觉得直接一步到位吧，不要弄过渡了

[RPRX]

@KobeArthurScofield 我把仓库名改成了 go-win7

[KobeArthurScofield]

我觉得直接一步到位吧，不要弄过渡了

这两天有可能能做出来，自动编译问题不大，难的是不知道会不会被上游更改来个 1.21.5 那样的情况

如果这几天还要发 v24 可以不用等这个

[RPRX]

如果这几天还要发 v24 可以不用等这个

不急，这个放 v25

[KobeArthurScofield]

• 自动化编译修补过的 go 工具链并且发布在 go-win7 的 release 中
• 上游发布新版时自动化跟进（存疑，因为需要测试实际是否没有 break win7，但是没有 win7/server 2008 的 runner）
• 构建版本时从 go-win7 自动下载并应用 latest 版本工具链
• Go 1.23 修补后可用于 win7
• Go 1.24 修补后可用于 win7 （现阶段，因应上游部分改动，patch 也有所调整，而且正式版发布之前可能还有不兼容调整）

如果没有其它细节需要调整那么这个 pr 就相当于可用状态了。

另外不清楚 Go 1.25 上游会不会有更大的更动，这个可能会影响日后对 Go 使用 patch 的维护难度。 v25 看起来还可以保留 win7 兼容，不过 v26 要不要重新考虑下？

[RPRX]

要不今天发个版吧，不然都 2025 了还在搞 v24，感觉好旧

[RPRX]

感谢贡献，我觉得更大的意义在于它为 custom Golang 开了个头，至于今天发不发版，暂不确定

[RPRX]

@KobeArthurScofield 对了你可以在这个项目 https://github.com/XTLS/go-win7 放一些说明，方便其它项目使用，有广泛价值

[alphax-hue3682]

感谢贡献，我觉得更大的意义在于它为 custom Golang 开了个头，至于今天发不发版，暂不确定

Hello, I think yesterday's version should be deleted and today's version should be published because it is the first day of the new year

[RPRX]

@alphax-hue3682 计划是等下发个版，然后先把昨天的版本设为 latest，明天写一下今天的版本的 release note 并设为 latest

[RPRX]

这个 PR 把 - "**/*.go" 注释掉了导致未能正确 trigger

打算改成所有 Build & Test 响应所有 branches & files，但 docker 保持只基于 main

[KobeArthurScofield]

对了你可以在这个项目 https://github.com/XTLS/go-win7 放一些说明，方便其它项目使用，有广泛价值

这个可以，几天内就好

这个 PR 把 - "**/*.go" 注释掉了导致未能正确 trigger

修改方案时的疏漏，在切换时漏掉了