GC频繁触发主因是代码“偷偷造垃圾”，需先通过逃逸分析定位堆分配热点，再用sync.Pool复用对象，最后才调整GOGC参数。
GC频繁触发，先看是不是内存泄漏或逃逸了
GC每分钟触发好几次，CPU狂飙、吞吐掉一半？别急着调 GOGC，90% 的情况是代码在“偷偷造垃圾”——比如循环里反复 make([]byte, n)、返回局部变量地址导致栈对象逃逸、闭包捕获大结构体等。Go 的 GC 是按堆增长率触发的，默认 GOGC=100，意味着堆只要翻倍就开扫。如果堆本身就在持续上涨（MemStats.HeapInuse 不回落），那调高 GOGC 只是把问题拖得更久，最终 OOM。
- 用
go run -gcflags="-m -m"查逃逸：重点盯住... escapes to heap的行，尤其是函数返回值、闭包变量、切片 append 后赋值等场景 - 用
go tool pprof抓堆分配热点，看哪些函数在高频 new/makehttp://localhost:6060/debug/pprof/heap - 检查全局 map/slice 是否不断增长没清理，或 HTTP handler 中未释放的中间结构体
sync.Pool 复用对象，但得会重置、别乱塞指针
sync.Pool 是缓解高频分配最直接的手段，但它不是“丢进去就能用”的缓存池。Pool 里的对象随时可能被 GC 清掉，而且它按 P 分片，跨 goroutine 获取不保证是同一个实例。更重要的是：带指针的大结构体放进 Pool，只是省了分配，没省扫描——GC 仍要遍历每个字段。
- 适合放：固定大小的
[]byte缓冲、JSON 解析用的临时map[string]interface{}、HTTP header 解析器等生命周期短、结构简单、可快速初始化的对象 - 必须做：每次
Get()后判空 + 重置状态，比如buf = buf[:0]；避免复用含未清零字段的 struct - 避免放：
*http.Request、含sync.Mutex或context.Context的结构体、大 slice（如[]int64超过几万元素）
GOGC 怎么调才不翻车
GOGC 是唯一能 runtime 修改的 GC 参数，但它不是万能油门。设太低（如 30）会让 GC 频繁 STW，尤其在容器内存受限时反而 CPU 更高；设太高（如 500）又可能让堆冲到 2GB 还不回收，触发 OS OOM Killer。关键看你的服务类型：
- 低延迟服务（API 网关、实时信令）：用
GOGC=30~50+GOMEMLIMIT=450MiB（比容器 limit 少留 10%），靠早回收压低单次停顿 - 批处理任务（日志归档、报表生成）：用
GOGC=200~300，减少 GC CPU 开销，但必须监控MemStats.Sys防止吃光系统内存 - 运行时动态调：用
debug.SetGCPercent(200)替代环境变量，方便在初始化后根据负载调整，记得保存旧值以便回滚
大内存块分配后，记得 nil + runtime.GC()
一次性分配几百 MB 的切片（比如 make([]byte, 300e6)），Go 会为它单独分配 span，并在后续每次 GC 都扫描这个巨无霸——哪怕你下一秒就不用了。这不是 bug，是设计使然。此时“等 GC 自己来”效率极低。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用完立刻
largeBuf = nil，再紧跟runtime.GC()强制回收该 span - 注意：仅限真正“用完即弃”的大块内存，比如初始化加载配置、预热缓存、批量解析原始数据等场景
- 别滥用：在请求处理循环里每轮都这么干，等于主动制造 STW 尖峰，得不偿失
GC 优化的本质不是和 runtime 对抗，而是帮它少干活、快干活。逃逸分析、对象复用、参数适配这三件事，顺序不能乱：先让对象尽量不上堆，再让上堆的对象尽量复用，最后才考虑放宽 GC 的节奏。很多团队一上来就调 GOGC，结果发现 gctrace 里标记阶段耗时依然 3ms——那说明对象图太重，得回去砍结构体字段、拆嵌套指针。
