Go 1.26 on Zampo Blog

同事甩 10–40% 截图让你升 Go 1.26？先量自己的 GC 占比

Fri, 17 Jul 2026 02:40:00 +0800

值班群里有人贴了 Go 官方的截图：Green Tea 能把 GC 开销降 10–40%。

下一句往往是：那下周就升 1.26，服务应该能快不少。

我会先去看一条监控：GC CPU 在总 CPU 里占多少。没有这个数，截图再漂亮，也不能替你做性能判断。

网上的 10–40% 说的是 GC 自己的 CPU，不是你的服务；先量自己的 GC 占比，再决定要不要为 Green Tea 做 A/B。

官方的说法有边界：对 GC 压力很重的真实程序，GC 开销预计可下降约 10–40%。多数程序接近 10%，少数可以接近 40%。这里减少的是垃圾回收本身消耗的 CPU 时间，不是 QPS 一定上涨，也不等于 p99 一定下降。

官方给过一个很实用的换算。如果一个程序有 10% 的 CPU 时间花在 GC，上述改善折算到总 CPU，大致是 1–4%。这个数字不小，但它和“服务快了 40%”是两回事。

你的服务里 GC 若只占 5% 的总 CPU，即便 GC 自身少花 40%，总 CPU 的变化也很有限。反过来，GC 在 CPU 性能分析里长期占着明显一段，或者分配频繁、堆里有大量小的指针对象，Green Tea 才值得认真对比。

这里没有玄学，先看两个数：GC CPU 占比，以及 GC 自身能少花多少。前者很低时，升级后业务指标没有明显变化，本来就是可能出现的结果。

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 开始，情况变了。不是因为你变勤快了，而是工具链开始替你动手了。

每到一个新版本，我们习惯先把 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 改进。