Go 1.26 Green Tea GC 怎么评估收益：标记扫描开销与回退开关

服务升级到 Go 1.26 后，GC 曲线没有明显变坏，但团队又不敢直接把“最高可减少 40% GC 开销”当成线上收益。这个判断是对的：Green Tea GC 优化的是小对象标记与扫描的局部性，结果取决于分配密度、CPU 架构和业务请求模型。评估时应保留默认实现，用同口径基准确认收益；只有复现出回归，才用 GOEXPERIMENT=nogreenteagc 做对照。

Go 1.26 的 Green Tea GC 值得评估，但不能凭一个官方区间换线上开关；先固定负载与资源，再比较 GC CPU、延迟和吞吐。

Go 1.26 Green Tea GC 改了什么，先看适用负载

Go 1.26 将 Green Tea GC 设为默认实现。它通过更好的页内局部性和 CPU 可扩展性，优化小对象的标记、扫描路径。官方给出的预期是：重 GC 负载下，实际 GC 开销可能降低约 10%–40%；较新的 amd64 平台还可能得到额外收益。这是工作负载范围，不是单个接口的 SLA。

先看三个信号：对象是否频繁分配且尺寸较小，GC 是否已经占到 CPU 的明显比例，以及延迟是否经常被回收周期牵动。若服务主要等待网络、磁盘或数据库，Green Tea GC 可能只改变 CPU 余量，不会直接让端到端延迟下降。

怎样做同口径基准，避免把噪声当收益

不要先改生产参数。准备两套完全相同的构建和输入：一套使用默认 Go 1.26，另一套只改变 GC 实现。固定 GOMAXPROCS、容器 CPU 与内存上限、请求并发、数据规模和预热时间，连续跑多轮，记录 p50/p95 延迟、吞吐、GC CPU、堆峰值和二进制大小。

可以把结论写成“在这类输入下，GC CPU 下降多少，业务延迟是否跟着变化”，而不是写成“升级后一定更快”。如果只有单轮结果，至少标注它是观察值；如果金丝雀与基线方向相反，先排查 CPU 限额、缓存命中率和请求分布，再进入回退实验。

# 仅示意实验变量，不在生产机上直接切换
go test -bench . -benchmem ./...
GOEXPERIMENT=nogreenteagc go test -bench . -benchmem ./...

用 nogreenteagc 定位回归，再决定上线策略

GOEXPERIMENT=nogreenteagc 是构建时回退开关，适合回答“回归是否随 Green Tea GC 消失”。它不能证明旧实现永远更好，也不能绕过版本升级带来的其他编译器、依赖或部署差异。默认构建和回退构建要在相同机器、相同输入下重复比较。

如果回退后结果恢复，先做小流量灰度并保留 GC 观测；如果两者差异不稳定，优先检查实验设计；如果默认实现更好，就不要为了熟悉旧行为长期关闭它。Go 1.26 还预期在后续版本移除这个回退选项，因此它应当是诊断工具，不是架构依赖。

把结果落成上线清单

评审记录至少保留四项：负载画像、两组构建的输入约束、GC 与业务指标差异、回滚和复测触发条件。这样即使换了机器或请求模型，也能知道哪些结论需要重新验证。默认实现没有回归时继续升级；确认回归时才进入灰度和问题跟踪。

常见问题

Green Tea GC 是否需要手动开启？

不需要，Go 1.26 已默认启用。先建立基线，只有定位问题时才考虑回退开关。

官方的 10%–40% 是接口延迟提升吗？

不是。它描述的是重 GC 负载下的 GC 开销预期，接口延迟仍要用自己的请求模型验证。

为什么回退后数据仍然没有改善？

可能瓶颈在网络、磁盘、锁竞争或下游服务；回退实验只能排除一部分 GC 因素。