应关注 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 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 仍在空转等待。
