Go服务内存持续上涨、GC停顿变长，主因是误将堆当临时缓存池；需正确使用sync.Pool（Get后Reset、Put前清空）、规避逃逸（用-gcflags="-m -l"分析）、合理设置GOGC，并警惕goroutine泄漏。
Go服务内存持续上涨、GC停顿时间变长、pprof显示大量*bytes.Buffer或[]byte堆积——这不是GC“不够强”，而是代码在无意中把堆当成了临时缓存池。
sync.Pool不是万能的，但不用它大概率会泄漏
很多开发者以为加了sync.Pool就万事大吉，其实关键在“复用逻辑是否闭环”。比如bytes.Buffer从池里取出来后没调用Reset()，下次再用时内部buf字段仍指向旧数据，导致对象无法被回收；又或者Put()前忘了清空敏感字段（如含token的结构体），还可能引发安全问题。
- 每次
Get()后必须显式重置状态：buf.Reset()、slice = slice[:0] -
Put()前检查对象是否已被外部引用（尤其含闭包或channel的结构体） - 不要把长生命周期对象（如全局配置、DB连接）塞进
sync.Pool——它只适合短命临时对象 - Pool大小无上限，滥用会导致内存滞留：监控
/debug/pprof/heap中sync.Pool相关分配量
逃逸分析结果比文档更可信
别信“这个结构体很小，肯定栈分配”——Go编译器只认逃逸规则，不认主观判断。一个string参数传给fmt.Println()就会逃逸，因为fmt底层用interface{}接收；返回局部变量指针必然逃逸；哪怕只是把变量地址存进map[string]*T，也会触发逃逸。
- 用
go build -gcflags="-m -l"看真实逃逸结果，重点扫... escapes to heap行 - 避免在热路径上做
interface{}转换，比如日志函数优先用fmt.Printf而非log.Printf（后者参数全为interface{}） - 结构体内嵌
sync.Mutex会导致整个结构体逃逸——改用指针字段*sync.Mutex可缓解 - 切片预分配容量能减少扩容逃逸：
make([]int, 0, 1024)比make([]int, 0)更安全
GOGC调低不等于更省内存
把GOGC从默认100调成20，确实会让GC更频繁地运行，但代价是CPU占用上升、STW次数翻倍。对延迟敏感的服务（如API网关），反而可能因GC抖动导致P99延迟飙升；而对吞吐型服务（如日志批处理），适当压低GOGC能防止内存雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 线上调整前务必用
runtime.ReadMemStats()采集基线：关注NextGC和PauseTotalNs趋势 - 配合
debug.SetMemoryLimit()（Go 1.21+）设硬上限，避免OOM killer介入 -
GOGC=off仅用于调试，生产环境禁用——手动调runtime.GC()风险极高 - 注意
GOGC影响的是“增量阈值”，不是绝对内存值：堆从100MB涨到200MB触发GC（GOGC=100），若调成50，则涨到150MB就触发
goroutine泄漏比内存泄漏更难发现
pprof的/debug/pprof/goroutine?debug=2里躺着几百个select { case 阻塞态goroutine，往往意味着channel没人关闭，或者context没传递到底层。这类泄漏不会立刻吃光内存，但会持续占用<code>mcache和栈空间，最终拖垮调度器。
- 所有启动goroutine的地方，必须配对
ctx.Done()监听或sync.WaitGroup等待 - 用带缓冲的channel替代无缓冲channel，避免发送方永久阻塞
- 定时器
time.AfterFunc或time.Ticker必须显式Stop()，否则底层goroutine永不退出 - 检查
net/http中间件是否意外捕获了request context并长期持有
真正卡住Go服务的，往往不是GC算法本身，而是开发者对“自动管理”的过度信任——内存不会自己消失，goroutine不会自己退出，逃逸路径不会自己收敛。每个new、make、go都得有明确的生命周期终点。
