runtime.NumGoroutine() 持续上涨是协程泄漏最直接信号，需排除初始化波动，重点观察请求后不回落或长期单调上升趋势；结合 pprof/goroutine 快照对比定位新增阻塞协程，辅以 goleak 在测试阶段拦截泄漏。
用 runtime.NumGoroutine() 快速确认是否真泄漏
协程数持续上涨是泄漏最直接的信号，但得先排除“正常波动”。比如 HTTP 服务刚启动时协程数可能跳到 100+，这是 pprof、日志、健康检查等后台 goroutine 在初始化，不是泄漏。
真正要盯的是：单次请求处理完后，总数不回落；或服务稳定运行几小时后，数字呈单调斜线上升（如从 50 → 200 → 800）。
- 在关键路径（如 HTTP handler 入口和出口）加一行：
log.Printf("goroutines: %d", runtime.NumGoroutine()) - 别只看一次——至少打 3 组时间点日志（空闲态、压测中、压测后 30 秒），才能判断趋势
- 注意：
runtime.NumGoroutine()返回的是当前存活的 goroutine 总数，包括已阻塞、已休眠、正在运行的，所以它不能告诉你“哪里卡住”，只负责回答“是不是在涨”
用 /debug/pprof/goroutine?debug=1 抓堆栈定位阻塞点
确认数量异常后，下一步是看“谁没退”，而不是猜。pprof 的 goroutine profile 是生产环境唯一可靠的一手信息源。
- 确保导入了：
import _ "net/http/pprof"，并启用了调试服务（如go func() { http.ListenAndServe("localhost:6060", nil) }()） - 访问
http://localhost:6060/debug/pprof/goroutine?debug=1，你会看到所有 goroutine 的完整调用栈，按状态分组（running、chan receive、select、sleep等） - 重点关注处于
chan receive或select且没有超时分支的 goroutine——它们大概率在等永远不会来的信号 - 别只扫一眼：把页面内容保存为文本，用
grep -A5 -B2 "your/pkg/name"锁定业务代码位置
对比两次快照，精准识别新增泄漏 goroutine
很多泄漏是“缓慢积累”的，单次快照里混着大量正常长期运行的 goroutine（比如 ticker、日志 flusher），靠肉眼很难分辨哪些是新长出来的。
立即学习“go语言免费学习笔记（深入）”；
- 第一次采集（系统空闲时）：
curl "http://localhost:6060/debug/pprof/goroutine?debug=1" > before.txt - 执行可疑操作（如调用某个 API 10 次）后，立即第二次采集：
curl "http://localhost:6060/debug/pprof/goroutine?debug=1" > after.txt - 用
diff before.txt after.txt | grep "^+" | grep -E "(chan receive|select|sleep)"过滤出新增且阻塞的 goroutine - 这些新增项的调用栈顶部，基本就是泄漏源头——比如显示
myapp/handler.go:42和net/http/transport.go:1293，就该立刻检查 resp.Body 是否 close
测试阶段用 goleak.VerifyNone(t) 拦截泄漏于开发早期
线上才发现泄漏，说明测试环节漏掉了。goleak 是目前最轻量、最准的单元测试级检测工具，它不依赖运行时环境，也不需要你手动比对快照。
- 在
TestMain中加入：goleak.VerifyNone(t)，它会在所有测试跑完后自动检查是否有 goroutine 残留 - 一旦失败，错误信息直接给出泄漏 goroutine 的启动栈，例如：
leaky_test.go:27: goroutine leak: goroutine 12 [chan receive] - 注意两个常见误报点：未关闭的
http.DefaultClient连接池（需在测试后调用http.DefaultTransport.(*http.Transport).CloseIdleConnections()）、或测试中启用了未 stop 的time.Ticker - 它不检测“逻辑上该退但还没退”的情况（比如 context 超时设得太长），只抓“彻底卡死、永远无法退出”的 goroutine
真正难的不是发现泄漏，而是区分“设计如此的长期 goroutine”和“本该退出却卡住的泄漏”。比如一个常驻的 metrics collector 是合理的，但同一个函数里多启了一个没传 context 的 for-select 就是 bug。每次看到新增阻塞 goroutine，先问一句：它的退出条件是什么？那个条件，在当前代码路径下，有没有可能永远不满足？
