GC停顿是否真为瓶颈需三重验证：单次STW＞5ms且频次达100–200ms/次、HeapLive持续上涨、平均停顿＞10ms或每分钟GC超30次；GOGC过低反增调度压力，GOMEMLIMIT须配合GOGC使用且单位为字节；sync.Pool滥用易致泄漏与panic。
别急着改 GOGC，90% 的新手调优失败，是因为没确认 GC 真是瓶颈，或者改了参数却让 OOM 来得更快。
怎么判断 GC 停顿是不是真问题？
延迟高、CPU 飙升，不等于 GC 在背锅。先看证据：
- 用
go tool trace打开 trace 文件，在 timeline 里找标着GC STW的横向条——如果单次宽度 > 5ms，且每 100–200ms 就出现一次，才值得深挖 - 启动时加
GODEBUG=gctrace=1，盯住日志末尾的三个数字，比如512->520->256 MB：最后一个（HeapLive）持续上涨，说明对象根本没被释放，调参没意义 - 运行中调
runtime.ReadMemStats()，算平均停顿：PauseTotalNs / NumGC> 10ms 才算异常；若停顿短但次数多（比如NumGC每分钟超 30），大概率是GOGC过低或堆增长失控
GOGC=50 真比默认值更“快”吗？
不是。它只是让 GC 更早触发，但不缩短单次停顿，反而可能加重调度压力：
-
GOGC=50意味着“新分配堆达到上次 GC 后存活堆的 1.5 倍就触发”，频率翻倍 →PauseTotalNs可能不降反升，尤其在高并发下 goroutine 抢占延迟会盖过 GC 本身 -
GOGC=200适合内存充足、延迟敏感度低于吞吐的场景（如实时推送服务），但必须配合GOMEMLIMIT，否则容器里 RSS 涨到被OOMKilled - 绝对不要设
GOGC=0或负数——Go 会静默忽略，退回到默认值 100，你还以为生效了
GOMEMLIMIT 必须和 GOGC 配合用
GOMEMLIMIT 是 Go 1.19+ 的软上限，但它不是 GOGC 的替代品，而是兜底机制：
立即学习“go语言免费学习笔记（深入）”；
- 单位必须是字节数，比如容器限制 4GiB，想留 20% 余量，就设
GOMEMLIMIT=3435973836（即 3.2GiB），不能写"3.2G" - 单独设
GOMEMLIMIT很危险：内存快满时才猛扫，Mark Termination阶段容易飙升；理想组合是GOGC=150主导常规节奏 +GOMEMLIMIT防临界 OOM - 在 Kubernetes 中，
GOMEMLIMIT应略高于压测实测常驻内存（如稳定 800MB，设 1GB），太低（如 512MB）会导致 GC 频繁、CPU 反升
sync.Pool 用错比不用还糟
它对 ≤32KB 小对象有效，但滥用会掩盖真实内存问题，甚至引入泄漏：
- Put 前必须
Reset()，比如bytes.Buffer.Reset()，否则下次 Get 到的是带旧数据的脏对象 - 别把含
context.CancelFunc的结构体放进 Pool——CancelFunc 会绑定 goroutine，导致泄漏 - 误当全局缓存长期持有大对象？Pool 会在每次 GC 前被清空，长期持有 = 白费力气 + 堆虚高
- 含指针的结构体 Put 前没清空字段，Get 后直接用，可能读到上一轮残留的指针，引发 panic 或数据错乱
真正卡住 STW 的，往往是 Mark Termination 阶段——它扫描灰色对象并处理 finalizer。对象越重（比如嵌套 map[s]truct{slice[interface{}]）、finalizer 越多，这阶段越慢。参数调得再细，也救不了堆里塞满深层指针链的代码。
