低延迟服务推荐 GOGC=50 起步，若 STW 超 0.8ms 再降至 30 并配 GOMEMLIMIT；禁用 runtime.GC()；高吞吐批处理可用 GOGC=200～500 但需严控内存；GOGC=off 禁止用于生产。
低延迟服务该设 GOGC=30 还是 50？
对实时交易、游戏后端、API 网关这类服务，单次 GC 停顿超过 1ms 就可能丢请求或卡帧。GOGC 不是越小越好——设成 GOGC=20 会让 GC 频率翻倍，CPU 开销陡增，反而拖慢整体吞吐。
推荐从 GOGC=50 起步：堆增长 50% 就触发回收，能压住峰值内存又不至于让 GC 太“喘不过气”。若实测 GODEBUG=gctrace=1 输出中仍有 >0.8ms 的 STW，再降到 GOGC=30，并务必搭配 GOMEMLIMIT=450MiB（假设容器 limit 是 512MiB），防止 GC 来不及介入就被 OOMKilled。
- 禁用
runtime.GC()手动触发——它会强制 STW，破坏低延迟稳定性 - 必须开
GODEBUG=gctrace=1观察实际 pause time，别只看配置改了没 - 如果停顿仍高，大概率是对象逃逸严重，用
go tool pprof -alloc_space查分配热点，而不是继续调低 GOGC
高吞吐批处理能不能设 GOGC=500？
可以，但得盯紧内存。日志聚合、ETL、离线计算这类任务不care单次延迟，更怕 GC 抢 CPU。设 GOGC=200～500 能显著降低 GC 次数，但代价是堆可能膨胀到上次 GC 后存活量的 3～5 倍。
比如上次 GC 后存活 200MB，GOGC=500 意味着要等堆涨到 1200MB 才触发下一次——这在裸机上没问题，在 K8s 里可能直接被 kill。
- 必须监控
MemStats.Alloc和MemStats.Sys，发现Alloc持续单向上涨就说明有泄漏，不是 GC 能解决的 - 避免在循环里
make([]byte, 1 这种大对象分配，哪怕 GOGC 再高，也会触发辅助 GC 导致抖动 - 优先用
sync.Pool复用缓冲区，比调高 GOGC 更治本
GOGC=off 或 SetGCPercent(0) 能不能用？
不能用于生产环境，哪怕只是“临时试试”。GOGC=off 或 debug.SetGCPercent(0) 会完全禁用 GC，堆内存只增不减，直到 OOM 或进程崩溃。
它只适用于极少数调试场景：比如想复现某个对象泄漏路径，或验证某段代码是否真没分配堆内存。用完立刻恢复，且必须在隔离环境运行。
-
GOMEMLIMIT和GOGC=off互斥，Go 1.19+ 会 panic - 即使设了
GOGC=off，runtime 仍可能因栈溢出、mmap 失败等底层原因强制触发 GC，行为不可控 - 线上误配的典型现象：Pod 内存使用率缓慢爬升至 100%，然后被 kubelet OOMKilled，日志里却看不到任何 GC 日志
为什么调了 GOGC 却没看到 GC 次数变化？
因为 GC 没触发条件。GOGC 控制的是“堆增长比例”，不是“时间间隔”或“分配次数”。如果应用本身分配极少（比如纯计算型服务），或者大量对象都分配在栈上（逃逸分析优化充分），堆压根不涨，GOGC 再小也没用。
验证是否生效，别只看配置，要看运行时指标：
- 用
runtime.ReadMemStats(&m)定期采样：m.NumGC是否随负载上升而增加 - 观察
m.HeapInuse是否在合理区间波动，而非持续单边增长 - 检查
m.PauseNs最近几次停顿时间，确认是否真的变短/变长
很多团队卡在这一步：改完 GOGC 就以为万事大吉，结果延迟抖动依旧，最后发现是 goroutine 泄漏或缓存未清理——GC 参数只是工具，不是万能解药。
