该调GOGC的信号是：go tool trace显示GC pause占请求延迟5%以上，且PauseTotalNs/NumGC平均单次停顿＞10ms，同时gctrace日志中HeapLive稳定小幅波动，表明对象确被回收；此时才应AB测试GOGC=75与125。
什么时候该调 GOGC，而不是一上来就改
多数服务 GC 问题根本不是参数导致的，而是代码里藏着缓存泄漏、goroutine 泄漏或 sync.Pool 误用。比如用 go-cache 时设了 cache.NoExpiration 存大对象，janitor 清不掉，HeapLive 持续上涨——这时候调 GOGC=50 只会让 GC 更频繁地扫一堆根本回收不了的对象，STW 次数翻倍，延迟反而更抖。
真正该调 GOGC 的信号是：go tool trace 显示 GC pause 占请求延迟 5% 以上，且 runtime.ReadMemStats 中 PauseTotalNs / NumGC 平均单次停顿 >10ms；同时 GODEBUG=gctrace=1 日志里 512->520->256 MB 这三段中最后一个数字（HeapLive）稳定在某个值上下小幅波动，说明对象确实在被回收。
- 确认后再试：先跑
GOGC=75和GOGC=125做 AB 测试，别硬编码进代码 -
GOGC=0或负数会被 Go 静默忽略，退回到默认 100，别信它生效了 - 容器环境必须配
GOMEMLIMIT，否则 RSS 会涨到被 OOMKilled
sync.Pool 用错比不用还伤 GC
sync.Pool 不是缓存，也不是对象池管理器，它是为“短生命周期、小对象（≤32KB）、无跨 goroutine 引用”场景设计的临时复用机制。滥用它会让 GC 更难判断哪些内存真能回收。
典型错误包括：
立即学习“go语言免费学习笔记（深入）”；
- Put 一个含
context.CancelFunc的结构体进 Pool，CancelFunc 持有 goroutine 引用，导致泄漏 - Get 后没调
Reset()（如bytes.Buffer.Reset()），下次 Get 到的是带脏状态的老对象，可能隐式延长指针存活时间 - 把大对象（如几 MB 的 map 或 slice）塞进 Pool，它不会被复用，但会虚高
HeapLive，误导 GC 触发时机 - 认为 Pool 是全局长期存储，结果对象在每次 GC 前被清空，业务逻辑却依赖“一直存在”
并发任务密集时，GC 停顿容易被误判为调度卡顿
高并发 HTTP 服务里，如果 trace 中看到大量 GC pause 与 Proc status change 重叠，别急着调 GC 参数。Go 的辅助标记（Mutator Assist）会在 GC 标记阶段让正在运行的 goroutine 主动帮着标记，此时若某个 handler 执行过久（比如同步调用慢 DB、没设 timeout 的 HTTP client），就会拖慢整个标记进度，表现为“GC 时间长”，实际是业务阻塞了 GC，不是 GC 拖慢了业务。
排查重点：
- 看
GODEBUG=gctrace=1输出中0.12/0.039/0.030这三段：中间那个（标记耗时）飙升，大概率是被长时间运行的 goroutine 卡住 - 用
go tool pprof -http看goroutineprofile，找阻塞点，而不是盯着heapprofile - 避免在关键路径上做同步 IO；所有外部调用必须设 timeout + context deadline
GOMEMLIMIT 在容器里不是可选项
Kubernetes 默认不限制容器内存上限，而 Go 1.19+ 的 GOMEMLIMIT 是按 RSS（常驻集大小）设硬限，不是堆大小。如果只设 GOGC=200 却不设 GOMEMLIMIT，Go 运行时会不断分配内存直到 RSS 接近宿主机物理内存，最终被 cgroup OOMKilled——这时日志里甚至看不到 GC 日志，因为进程直接被杀了。
安全做法：
- 容器
resources.limits.memory设为 1Gi，则GOMEMLIMIT最多设 800Mi（留 200Mi 给 runtime 和 OS） - 搭配
GOGC=125使用，避免因内存紧张触发过于频繁的 GC - 上线前用
stress-ng --vm 1 --vm-bytes 512M类工具压测 RSS 上升趋势，验证是否在 limit 内平稳运行
GC 调优最易被忽略的一点：它永远无法修复泄漏。HeapLive 持续上涨，第一反应不该是调参，而是查 pprof heap 里 top allocs 和 inuse_space，定位谁在持续 New 对象却不释放。
