runtime.NumGoroutine()持续上涨是协程泄漏最直接信号，需排除初始化波动，重点监控请求后不回落或长期单调上升；配合pprof快照对比、goleak测试拦截及channel/context规范使用定位修复。
用 runtime.NumGoroutine() 快速确认是否真泄漏
协程数持续上涨是泄漏最直接的信号，但得先排除“初始化波动”——比如服务刚启动时从 5 跳到 80+，很可能是 pprof、健康检查、日志采集等后台 goroutine 在拉起，不是泄漏。
真正要盯的是：单次请求处理完后总数不回落；或稳定运行几小时后呈单调上升（如 60 → 240 → 960）。
- 在 HTTP handler 入口和出口各打一行：
log.Printf("goroutines: %d", runtime.NumGoroutine()) - 至少采 3 个时间点：空闲态、压测中、压测后 30 秒——只看一次数字毫无意义
- 别用
time.Sleep(100 * time.Millisecond)就断言没泄漏：有些 goroutine 依赖超时或外部事件退出，建议配合time.AfterFunc或显式done chan struct{}等待其完成 - 系统 goroutine 有浮动（GC、timer 等），建议采样 3 次取最小值作 baseline，或直接上
goleak自动过滤
用 net/http/pprof 定位阻塞点和调用栈
runtime.NumGoroutine() 告诉你“有事”，pprof 告诉你“什么事、在哪行、为什么卡住”。
- 导入
_ "net/http/pprof"，再起一个独立 goroutine 监听:6060，零业务侵入 - 访问
http://localhost:6060/debug/pprof/goroutine?debug=1查看所有活跃 goroutine 的当前堆栈；加?debug=2还能显示 blocking channel 的 sender/receiver 信息 - 重点筛状态为
chan receive、select、semacquire或长时间sleep的 goroutine——它们大概率就是泄漏源 - 对比快照：服务刚启动抓一次（A），跑 5 分钟后再抓一次（B），用
diff -u A B | grep "^+"找新增堆栈，直指问题函数
用 goleak.VerifyNone(t) 在测试阶段自动拦截
这是开发阶段最轻量也最可靠的检测手段，但它只在测试里起作用，不适用于线上监控。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go get -u github.com/uber-go/goleak - 在 Test 函数末尾加
defer goleak.VerifyNone(t)（必须 defer，否则 panic 时不执行） - 它会检查 test 结束后是否还有非系统 goroutine 残留，默认忽略标准库启动的（如
net/http监听协程） - 如果你手动起了
http.Server，需显式忽略：goleak.IgnoreCurrent()或传goleak.Option过滤掉已知安全堆栈
修复泄漏前先搞清常见诱因
90% 的泄漏来自 channel 使用不当。核心原则是：谁创建 channel，谁 close；谁接收，谁负责退出条件；谁启动 goroutine，谁确保它能结束。
- 忘记关闭 channel：比如
for range ch的接收方永远等不到close(ch) -
select缺少default或未处理ctx.Done()，导致无限循环卡在某个 case - 启动 goroutine 后丢了引用（没存进 map/slice，也没用
sync.WaitGroup等它） -
http.Server关闭后仍有 handler goroutine 在跑——没等 handler 返回就关 server，或 handler 里启了没管控的子 goroutine
复杂点在于：泄漏往往不是单点错误，而是多个协作环节松耦合导致的“退出信号丢失”。比如 context 传了一半就断了，channel close 被 defer 在错误作用域，或者 goroutine 启动后没人监听它的 done 通知——这些细节，光看数字发现不了，得靠快照对比和调用栈下钻。
