GC调优须先确认瓶颈真在GC：用gctrace看HeapLive是否持续上涨，结合ReadMemStats验PauseTotal占比与NumGC频率；HeapLive涨说明代码泄漏，非参数问题；GOGC仅控触发时机，盲目调低增STW次数，调高不配GOMEMLIMIT易OOM；sync.Pool滥用反加重压力。
GC 参数调优不是“设个 GOGC 就完事”，而是先确认问题真出在 GC，再决定动不动参数、怎么动。盲目调低 GOGC 可能让 STW 次数翻倍，调高又可能让容器被 OOMKilled——多数性能抖动根本不是 GC 没调好，是代码在持续制造不可回收的对象。
怎么看 GC 真是不是瓶颈
别只盯着 CPU 高或延迟毛刺就怀疑 GC。先用 GODEBUG=gctrace=1 启动程序，观察日志里类似 512->520->256 MB 这样的三段数字：
- 第一个数（512）是上轮 GC 前的堆分配量（
HeapAlloc） - 第二个数（520）是 GC 开始时的堆大小
- 第三个数（256）是 GC 结束后存活对象大小（
HeapLive）
重点盯最后一段：HeapLive 如果持续上涨（比如 256→280→310→350），说明对象根本没被释放，调参毫无意义，得查代码泄漏、缓存未清理或 sync.Pool 用错；如果 HeapLive 稳定但 HeapAlloc 在两次 GC 间暴涨（100MB → 400MB），才是分配过猛，该看逃逸分析。
再配合 runtime.ReadMemStats 查三个字段：
立即学习“go语言免费学习笔记（深入）”；
-
NumGC：单位时间 GC 次数是否 >10 次/秒 -
PauseTotalNs：所有 STW 时间总和是否占请求耗时 >5% -
HeapInuse：pprof heap profile 里是否持续上涨
GOGC 不是性能开关，是触发阈值
GOGC 控制的是“新分配堆达到上次 GC 后存活堆的多少百分比时触发”，公式是：目标堆 = HeapLive × (1 + GOGC/100)。默认 GOGC=100 意味着翻倍就 GC。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设成
GOGC=50：不是“更勤快”，而是 GC 频率翻倍，STW 次数上升，goroutine 抢占延迟可能反超 GC 停顿本身 - 设成
GOGC=200：只在内存充足且延迟敏感度低于吞吐时合理；容器环境必须同步配GOMEMLIMIT，否则 RSS 涨到宿主机 OOMKilled - 绝对不要设
GOGC=0或负数——Go 会静默忽略，退回到默认值，你还以为生效了
生产环境优先用运行时命令做 AB 测试：GOGC=75 或 GOGC=125，而不是硬编码进代码。
GOMEMLIMIT 是容器环境的强制安全阀
Kubernetes 的 resources.limits.memory 对 Go 运行时不可见。GOGC 默认仍按宿主机内存估算目标堆，极易触发 OOMKilled。必须设 GOMEMLIMIT，且值要留余量：
- 容器 limit=2Gi →
GOMEMLIMIT=1900Mi（留 100Mi 给 runtime 元数据、goroutine 栈、mmap 区域） - 不要设成刚好 2Gi，也不要设太低（如 512Mi），否则 GC 频繁触发，CPU 占用反升
-
GOMEMLIMIT和GOGC共存时，谁先到谁触发；设了GOMEMLIMIT后，GOGC实际影响范围会收窄
验证是否生效：开 GODEBUG=gctrace=1，看日志中 MB goal 是否明显压低（比如理论该是 300MB，实际显示 180 MB goal）。
sync.Pool 用错比不用还糟
sync.Pool 不是缓存，是“短期对象回收加速器”。滥用会掩盖真实内存问题，甚至加重 GC 负担：
- Put 前不
Reset()（如bytes.Buffer.Reset()），下次 Get 到的是脏数据，残留内容可能隐式扩容并逃逸 - 把含指针的结构体放进 Pool 后没清空字段，导致 goroutine 泄漏（比如带
context.CancelFunc） - 误以为 Pool 是全局缓存，长期持有大对象——它会在每次 GC 前被清空
-
New函数必须返回全新对象，不能复用全局实例（否则并发 Get() 会读写同一块内存）
真正难的从来不是参数怎么设，而是分清：你是在优化 GC，还是在掩盖代码里持续制造不可回收对象的行为——后者才是绝大多数 GC 问题的根因。
