先确认停顿是否真由GC引起，再用go tool trace和GODEBUG=gctrace=1定位——多数卡顿源于mark termination阶段阻塞或非GC问题，而非参数本身。
别先改 GOGC 或 GOMEMLIMIT，先用 go tool trace 和 GODEBUG=gctrace=1 确认停顿是否真由 GC 引起——多数“卡顿”实际是 markTermination 阶段被阻塞，或根本不是 GC 问题。
怎么用 go tool trace 快速定位 GC 毛刺来源
启动程序时加 -gcflags="-l" -ldflags="-s -w"（避免内联干扰），再用 go tool trace 抓取 30 秒 trace：
- 在 timeline 上找标着
GC STW的红色横条：宽度 > 5ms 且与 P99 延迟尖峰对齐，才值得深挖 - 对比同时间的
Network、Sync、GoBlock事件：若 GC STW 很短但网络等待很长，别调 GC - 点开任意一次 GC，看
mark termination子阶段耗时占比：超过 60%，说明对象图太重或写屏障被拖慢，不是 GOGC 能解决的 - 注意
GC assist是否频繁亮起：亮得密，说明 mutator 正在被迫帮 GC 标记，通常是分配速率远超回收速率
GODEBUG=gctrace=1 日志里哪些数字真正关键
日志形如：gc 12 @3.456s 0%: 0.012+0.45+0.008 ms clock, 0.096+0.12/0.28/0.51+0.064 ms cpu, 12->12->8 MB, 13 MB goal，只盯这三组：
-
12->12->8 MB：第一个是 GC 前堆大小，第二个是 GC 后堆大小，第三个是HeapLive（当前存活对象）；若HeapLive持续上涨（比如从 8→10→13→16），说明对象没释放，调参无意义 -
13 MB goal：GC 目标堆大小，由GOGC和上次 GC 后HeapLive计算得出；若 goal 远大于HeapLive（如 goal=2GB，live=300MB），说明 GC 实际未触发，可能是sync.Pool虚高了统计 -
0.12/0.28/0.51中间那段（mark phase）飙升：大概率不是 GC 慢，而是标记被阻塞——查是否有长运行 goroutine、锁竞争或runtime.nanotime调用过多
GOGC 和 GOMEMLIMIT 怎么配才不翻车
二者不是互斥开关，而是分层协作：GOGC 控节奏，GOMEMLIMIT 守底线。错误配法会让停顿更糟：
立即学习“go语言免费学习笔记（深入）”；
- 容器中设
GOGC=200但没设GOMEMLIMIT：堆涨到 3GB 才 GC，markTermination时间可能飙到 100ms+，且 RSS 接近 cgroup limit 时会被 OOMKilled - 设
GOMEMLIMIT=512MB但容器内存限制是 1GiB：GC 频繁触发，CPU 占用反升，mutator assist成常态 - 正确组合示例：容器内存 limit=4GiB →
GOMEMLIMIT=3435973836（即 3.2GiB），GOGC=150；让 GOGC 主导常规节奏，GOMEMLIMIT 在堆逼近 3.2GiB 时提前一轮启动 GC，避开临界点 full mark - 绝对不要在 shell 脚本里写
export GOGC="100"（带引号）：Go runtime 会静默忽略，必须无引号
真正难的不是参数值本身，而是理解 HeapLive 和 goal 的差值意味着什么、为什么 markTermination 会卡住、以及 sync.Pool 里一个没 Reset() 的 bytes.Buffer 如何把 GC 周期压缩到 1.8 秒——这些细节藏在 trace 和 gctrace 的数字缝隙里，不在文档首页。
