你的旧 Go 代码，Go 1.26 能一键救回来

Mon, 13 Jul 2026 00:00:00 +0000

你有没有这种代码——

1
2
3


for i := 0; i < n; i++ {
 ...
}

Go 1.22 之后可以写成 for range n。你知道，但三年了，你还没改。

或者这种——

1
2


eq := strings.IndexByte(pair, '=')
result[pair[:eq]] = pair[1+eq:]

Go 1.18 就有 strings.Cut 了。你知道怎么用，但一直没动手。

我猜你的项目里不止一处这种「知道有更好的写法，但优先级排不上号」的代码。你甚至列过 Refactoring 工单，然后排到了下周，再然后就没有然后了。

这不是你的问题。这是大多数 Go 项目的真实状态：

知道该改，但没人专门花时间去改。

但从 Go 1.25 开始，情况变了。不是因为你变勤快了，而是工具链开始替你动手了。

真正的主角不是新特性，是 `go fix`

每到一个新版本，我们习惯先把 release notes 扫一遍，看有没有好用的新语法、新标准库。

但 Go 1.25 和 1.26 真正重要的变化，不在新特性本身，而在一个你可能忽略的子命令：

1

$ go fix ./...

go fix 不是什么新东西。它从 Go 1 就有了，以前只是偶尔用来修一下 build tag 格式之类的小补丁。但在 Go 1.26 里，它被彻底重写了——底层不再是独立代码，而是和 go vet 共用了同一个分析框架。

Thu, 25 Jun 2026 10:30:00 +0800

很多团队升级 Go 版本，只做一件事：把 CI 跑绿。

跑绿以后就结束了。代码没动，测试没动，工具链没动。版本号从 1.22 变成 1.26，心里安慰自己：至少我们没落后太多。

但 Go 1.25 / 1.26 这两版，我不太建议这样看。

它们最值得关注的地方，不是又多了几个语法点，而是 Go 开始把一些团队长期积着的工程债，往运行时、工具链和标准库里搬。

性能债，交给 Green Tea GC 先还一部分。

写法债，交给重写后的 go fix 先还一部分。

测试债，交给 testing/synctest 先还一部分。

这不是“新版 Go 很厉害”的发布稿口吻。真正值得你关心的是：有些债，以前只能靠团队纪律、代码评审和人肉迁移，现在开始有工具接手了。

Go 1.26 默认启用了 Green Tea GC。

如果只看传播口径，这个点很容易被写歪：最高 50%、零代码修改、重新编译就提速。听起来很爽，但这种说法最容易误导人。

Green Tea 真正改善的是 GC 这部分成本，不是你的业务整体性能直接涨 50%。

Go 官方更稳的说法是：对重度使用 GC 的真实程序，预期 GC overhead 降低 10% 到 40%。在较新的 amd64 CPU 上，因为可以用向量指令扫描小对象，还可能有额外的 GC overhead 改进。