Go服务内存只涨不跌、GC停顿变长、RSS逼近容器限制，根本原因并非GC故障，而是对象被钉住或参数与负载不匹配：延迟敏感服务宜设GOGC=50～75，吞吐型任务可用GOGC=125～200并配GOMEMLIMIT；pprof采样需加?gc=1强制GC后抓快照；sync.Pool误用、逃逸分析误判及未清理的ticker/map才是内存只升不降的元凶。
Go服务内存只涨不跌、GC停顿突然变长、RSS持续逼近容器限制——这些问题不是GC“坏了”，而是运行时在告诉你：有些对象正被悄悄钉住，或者调参方式和当前负载根本不匹配。
什么时候该调 GOGC，而不是硬写死值
默认 GOGC=100 意味着堆增长一倍就触发 GC，看似合理，但实际要看你的服务类型和内存水位：
- 延迟敏感型服务（如 API 网关）：GOGC=50～75 更稳妥，避免单次 GC 标记量过大导致 STW 抖动
- 吞吐优先型批处理任务：GOGC=125～200 可减少 GC 频率，但必须同步设
GOMEMLIMIT，否则 RSS 会一路冲到 OOMKilled - 绝对不要在代码里写
debug.SetGCPercent()并长期生效——它绕过环境变量控制，上线后无法热调整，AB 测试也难做 - 容器环境必须配对使用
GOGC和GOMEMLIMIT；只调前者不设后者，等于把内存上限交给宿主机决定，极大概率被 kill
pprof heap 快照为什么总抓不到泄漏点
不是 pprof 不准，而是采样姿势错了。真实泄漏对象往往跨 GC 周期存活，错误采样会让它们“隐身”：
- 采样命令里带
?gc=1（例如wget "http://localhost:6060/debug/pprof/heap?gc=1"）→ 强制 GC 后抓快照，把本该泄漏的长期存活对象一起刷掉了 - 两次快照间隔 HeapInuse 曲线看不出线性趋势
- 快照文件没用
.heap或.pb.gz后缀 →go tool pprof无法识别格式，后续top或focus全是错的 - 正确做法：先等服务跑稳（比如压测 5 分钟后），再执行
wget http://localhost:6060/debug/pprof/heap -O before.heap，等 45 秒，再wget ... -O after.heap
sync.Pool 用错比不用还危险
Pool 不是缓存，也不是对象池通用解法，它只在特定条件下省 GC，滥用反而加重负担：
立即学习“go语言免费学习笔记（深入）”；
- Put 进去的结构体含指针字段（比如
*bytes.Buffer或带context.CancelFunc的 struct），但没在Reset()里清空 → 下次Get()拿到的是脏数据，可能引发 goroutine 泄漏或 panic - 把 >32KB 的大对象塞进 Pool → runtime 会直接 bypass Pool，走常规堆分配，白费力气还污染本地缓存
- 在 HTTP handler 里 Put 一个生命周期绑定 request 的对象 → handler 结束后对象仍被 Pool 持有，但实际已不该存活，变成隐性泄漏
- Pool 中对象会在每次 GC 前被清空，所以它不适合存需要跨 GC 周期持久化的数据
逃逸分析结果怎么看才不被误导
go build -gcflags '-m' 输出的 “moved to heap” 不等于“一定有问题”，关键看逃逸是否必要：
- 返回局部变量指针（
return &x）必然逃逸 → 合理，不改 - 传入接口参数后，编译器为满足接口方法集而将整个 struct 分配到堆 → 可考虑改用指针接收者或拆分接口
- 闭包捕获了大数组或 map → 如果闭包只在函数内短期使用，可尝试用切片预分配 +
make([]T, 0, N)控制底层数组不逃逸 - 最易踩坑的是字符串拼接：
s := a + b + c在短字符串下不逃逸，但若其中任意一个是运行时拼出的（比如从 HTTP header 解析来），整个表达式大概率逃逸 → 改用strings.Builder显式控制
GC 调优真正的难点不在参数本身，而在区分“GC 在努力回收”和“GC 根本收不走”。很多线上问题查到最后，都不是 GOGC 设高了，而是某个 time.Ticker 忘了 Stop()，或者全局 map[string]*UserConfig 一直往里塞却从不删——这些“钉子”，才是让堆内存只升不降的元凶。
