GOEXPERIMENT 关闭新 GC 为什么对已构建程序无效

服务已经编译完成，值班时临时执行 GOEXPERIMENT=nogreenteagc ./server，GC 指标却没有变化，这个现象通常不是开关失效，而是设置时机错了。GOEXPERIMENT 影响的是 Go 构建链选择的 runtime，必须在 go build 阶段生效；它不会在进程启动时把旧二进制里的 GC 实现替换掉。

官方资料：https://go.dev/doc/go1.26

先看清 GOEXPERIMENT 的作用范围

Go 1.25 中 Green Tea GC 还是实验特性，Go 1.26 发布说明则写明它已经默认启用，并允许在构建时使用 GOEXPERIMENT=nogreenteagc 关闭。这里的关键词是“构建时”：环境变量先被 go 命令读取，再影响编译器和 runtime 的构建配置，最后才进入可执行文件。

所以要把三个对象分开看：构建机上的环境变量、构建过程产生的 runtime、部署目录中的二进制。只改第一个对象，且没有再次执行构建，后两个对象都不会变化。

为什么改环境变量不会改变已有二进制

启动命令中的环境变量只能成为进程环境的一部分。GC 算法选择不是普通的运行时参数，而是随工具链编译出的实现和实验配置一起进入制品。旧进程已经加载旧制品，重新 export 也不会触发链接、编译或 runtime 替换。

# 这个命令只是启动旧制品，不会重新编译 runtime
GOEXPERIMENT=nogreenteagc ./server

# 下面这一步才会让开关进入新的构建结果
GOEXPERIMENT=nogreenteagc go build -o dist/server-nogreenteagc ./cmd/server

排查时可以先比较部署文件的 SHA-256，再看构建流水线日志。若同一个文件的摘要没有变化，就不能把启动环境变量当作 GC 切换证据。反过来，两个摘要不同也只能说明制品不同，还要结合相同负载下的 GC CPU、暂停和堆曲线判断是否值得保留。

正确的关闭方式是重新构建并留痕

生产环境建议把退出开关写在构建任务，而不是写在启动脚本里。需要诊断标准库或依赖缓存影响时，可以临时使用 -a 强制重建；正常流水线则应固定 Go 版本、提交号和构建参数，让缓存由工具链自行判断。

# 构建阶段固定 Go 版本与退出开关，生成独立制品
export GOEXPERIMENT=nogreenteagc
go version
go env GOEXPERIMENT
go build -a -trimpath -o dist/server-nogreenteagc ./cmd/server

# 记录摘要，发布系统再把提交号和构建时间写入同一份清单
shasum -a 256 dist/server-nogreenteagc

默认构建的 dist/server 不要覆盖。让发布指针、容器标签或压缩包名称明确区分两种制品，灰度异常时直接切回默认版本。go env GOEXPERIMENT 只能证明当前构建命令看到的值，不能证明某个历史二进制当时使用了什么值，因此构建日志和制品清单必须一起保存。

上线前的回滚与排查清单

Go 官方资料还提示，这个退出选项预计会在 Go 1.27 移除，因此不要把它设计成长期配置中心开关。若关闭后性能反而下降，先恢复默认制品，再固定负载采样，最后把可复现的结果提交给 Go 项目，而不是在启动命令里反复改环境变量。

相关问题

已经运行的进程能否不重启就切换 GC？

不能依靠 GOEXPERIMENT 完成。它是构建期选项，需要生成新制品并通过正常发布流程替换进程。

为什么构建日志里有 nogreenteagc，运行结果却没有改善？

开关只决定构建分支，不承诺每种负载都更快。应先确认实际运行的是新哈希，再用同一负载比较 GC 指标。

是否应该长期关闭 Green Tea GC？

不宜直接长期固定。Go 1.26 把它设为默认，退出选项还有版本边界；除非有可复现的性能或行为问题，否则优先使用默认实现并持续观测。