应关注 alloc_space 增量而非 inuse_space，通过差分分析定位高频分配未释放代码；goroutine 泄漏关键在卡住不退的协程，需对比快照查 chan receive 等阻塞态；context.WithTimeout 需配合 ctx.Done() 监听与 channel 关闭。
只看 inuse_space 会漏掉 90% 的真实泄漏
很多开发者一打开 http://localhost:6060/debug/pprof/heap?gc=1 就盯着 inuse_space 最高的函数猛看，结果反复排查业务逻辑却一无所获。这是因为真正的泄漏（比如全局 map[string]*BigStruct 持续塞入、未关闭的 http.Response.Body、或 ticker 启动后没 Stop()）往往单次分配量小、残留内存少，在 inuse_space 里占比极低，但 alloc_space 却在持续上涨。
正确做法是做差分分析：
- 让服务空载稳定运行 1–2 分钟，执行
wget "http://localhost:6060/debug/pprof/heap?gc=1" -O heap1.pprof - 等待 3–5 分钟（避开压测波动期），再抓一次：
wget "http://localhost:6060/debug/pprof/heap?gc=1" -O heap2.pprof - 运行
go tool pprof -diff_base heap1.pprof heap2.pprof，然后用top查看alloc_space增量最大的函数 - 右键点击该函数 →
list，直接定位到哪一行代码在高频分配且未释放
goroutine 泄漏不是“数量多”，而是“卡住不退”
runtime.NumGoroutine() 返回的是总数，但真正危险的是长期处于 chan receive、select 或 semacquire 状态的 goroutine——它们不占 CPU，却死死拿着栈内存和所有被引用的对象。
排查必须对比两次快照：
立即学习“go语言免费学习笔记（深入）”；
- 服务刚启动、空载时抓一次：
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=1（保存为goroutines_init.pb.gz） - 跑 10 分钟后，再抓一次（
goroutines_later.pb.gz） - 用
go tool pprof -base goroutines_init.pb.gz goroutines_later.pb.gz，再top，重点看新增 goroutine 的调用栈 - 搜索关键词：
chan receive、IO wait、time.Sleep、select—— 几乎所有泄漏源头都藏在这几类堆栈里
别信 context.WithTimeout 就万事大吉
常见错误是写了 ctx, cancel := context.WithTimeout(...)，却在 goroutine 里漏掉了对 ctx.Done() 的监听，或者写成 for range ch 却没关 ch，导致即使上下文已超时，goroutine 仍在空转等待。
安全模式必须满足三点：
- 所有衍生 goroutine 必须接收
ctx参数，并在select中把放在第一个case - channel 由发送方显式
close(ch)，接收方用for msg := range ch或配合ok判断 - 定时器类操作必须
defer ticker.Stop()，哪怕加了ctx控制也不能省略
示例错误写法：for { select { case —— 没有退出路径，永远卡住；正确写法：for { select { case
测试阶段就该拉响警报，别等上线才查
pprof 是事后分析工具，而泄漏往往在开发早期就埋下。两个轻量但极其有效的“静默报警器”必须接入：
- 启动时加
GODEBUG=gctrace=1：观察 GC 日志中scvg是否频繁失败；若连续几次显示not enough heap，说明有对象被意外持有无法回收 - 单元测试统一用
github.com/uber-go/goleak：在TestMain中调用goleak.VerifyNone(m)，它会自动捕获测试结束后残留的 goroutine，并打印其创建位置——比翻日志快十倍
线上环境慎用 GODEBUG=goprobe=1（调度开销大），应改用 Prometheus 暴露 runtime.NumGoroutine() 指标，配 Grafana 告警：5 分钟内增长 >200 即触发人工介入。
