确认CPU高是否由GC引起需先看pprof CPU profile中runtime.gcDrainN等函数占比是否超20%，再结合-alloc_objects分析堆分配热点，辅以NumGC和PauseTotalNs判断GC频率与停顿是否异常。
怎么确认CPU高是GC引起的
别急着调参数，先看证据。pprof 的 CPU profile 里如果 runtime.gcDrainN、runtime.markroot、runtime.scanobject 占比超过 20%，基本就是 GC 在吃 CPU；再配合 go tool pprof -alloc_objects 看堆分配热点，若 top 函数大量出现在 JSON 解析、map 构建、切片扩容等路径，说明对象分配太猛，GC 被迫高频运转。
补充一个硬指标：用 debug.ReadGCStats 或 runtime.ReadMemStats 查 NumGC 和 PauseTotalNs，如果一分钟内 GC 次数 > 30 次，且平均停顿 > 1ms，就不是“正常节奏”，而是配置或代码在拖后腿。
GOGC 设太高会怎样
设 GOGC=200 不是“更省 GC”，而是让堆允许涨到上次 GC 后的 2 倍才触发回收——这意味着更多对象堆积、更大扫描量、更长标记时间。尤其在请求流量波动大时，一次突发分配可能直接拉高堆 3–4 倍，触发超长 STW，CPU 瞬间打满。
- 容器环境必须同步设
GOMEMLIMIT，否则 RSS 持续上涨，最终被 OOMKilled（GOGC再低也救不回来） -
GOGC=0或负数会被 Go 静默忽略，退回到默认值 100，你根本不知道它没生效 - 生产环境优先用运行时环境变量调整，比如
GOGC=75或GOGC=125做 AB 测试，别硬编码进debug.SetGCPercent
sync.Pool 用错反而加重 GC
很多人以为 Pool 是“万能缓存”，往里塞结构体、buffer、甚至带 context 的对象，结果适得其反：
立即学习“go语言免费学习笔记（深入）”；
- Pool 对小对象（≤32KB）有效，但 Put 进去的含指针结构体，若没手动清空字段，下次
Get()拿到的是脏数据，可能引发逻辑错误或内存泄漏 - HTTP handler 里 Put 一个带
context.CancelFunc的结构体，CancelFunc 持有 goroutine 引用，导致协程无法释放 - 每次
Get()后必须调用Reset()（如bytes.Buffer.Reset()），否则旧状态残留，等于白用 Pool - Pool 不是长期存储——它会在每次 GC 前被清空，误当全局缓存用，等于把压力又推回堆分配
真正该盯住的三个地方
GC 参数只是表象，背后永远是代码行为。排查时重点看：
- 有没有无休眠的 for 循环？比如收到
qferror.ErrNoTeu就死等不 sleep，协程空转吃满一个核 - JSON 反序列化是否重复执行？同一份 payload 在循环里解 6 次，每次分配新 map/slice，GC 直接过载
- 逃逸分析是否失控？用
go build -gcflags="-m"检查关键函数，若本该栈分配的struct{}被标为 “moved to heap”，就得重构传参方式或拆分逻辑
GC 不会自己变坏，它只是忠实地回收你不断制造的垃圾。参数调得再细，也盖不住每秒分配 10MB 临时对象的事实。
