用 runtime.NumGoroutine() 可快速检测协程泄漏：操作前后采样对比，差值超2~3需警惕；建议采样3次取最小值作基线，或配合 done chan 或 time.AfterFunc 确认退出，避免误判系统 goroutine 波动。
用 runtime.NumGoroutine() 快速验证测试里有没有漏掉协程
这是最轻量、最直接的“第一道筛子”，适合在本地跑单元测试或 CI 阶段快速拦截明显泄漏。它不告诉你哪一行出问题，但能立刻告诉你：“你写的这个函数，启动的协程没收拾干净。”
- 关键不是看绝对值，而是看「操作前后是否回归基线」：调用前记一次
runtime.NumGoroutine()，等足够久（比如time.Sleep(100 * time.Millisecond)），再记一次；差值超过 2~3 就要警惕 - 别只 sleep 一次就下结论——有些协程靠超时退出，有些等外部信号，建议配合
done chan struct{}或time.AfterFunc显式确认退出时机 - 系统 goroutine 有波动（GC、timer 等），采样 3 次取最小值作 baseline 更稳；或者直接用
goleak，它默认过滤掉已知安全的 stdlib 协程
示例中漏掉 close(ch) 或 sender，就会卡在 上不动，<code>NumGoroutine() 能立刻暴露这种低级但高频的问题。
用 net/http/pprof 查线上服务里卡死的协程在哪
当服务跑着跑着协程数从 50 涨到 800，NumGoroutine() 只会说“有事”，而 pprof 告诉你“什么事、在哪行、为什么卡”。它是生产环境定位泄漏的标配手段。
- 只需导入
_ "net/http/pprof"，再起个独立 goroutine 监听:6060，完全不侵入业务逻辑 - 访问
http://localhost:6060/debug/pprof/goroutine?debug=1看所有活跃协程堆栈；加?debug=2还能看到 channel blocking 的详细信息 - 重点盯状态为
chan receive、select、semacquire或长时间sleep的协程——它们大概率就是泄漏源 - 对比两次快照：刚启动时抓一次（A），压测/运行 5 分钟后再抓一次（B），用
diff -u A B | grep "^+"找新增堆栈，直指问题函数
用 goleak.VerifyNone(t) 在测试里自动揪出残留协程
它不是“导入就生效”的魔法库，而是需要你显式调用的守门人。适合集成进 Test 函数末尾，作为自动化防线。
立即学习“go语言免费学习笔记（深入）”；
- 必须写成
defer goleak.VerifyNone(t)，否则 test panic 时不会执行，等于白加 - 如果你的测试里合法启了后台 HTTP server，得加
goleak.IgnoreCurrent()，否则它会把 server 的监听协程当成泄漏 - 它默认只检查测试执行期间新增的协程，不扫描整个进程生命周期；若需更广覆盖，得配合
goleak.Cleanup()和自定义goleak.Option - 别在
init()或包变量初始化里拉起 goroutine——VerifyNone会把它当泄漏报出来
用 context.Context 主动控制协程生命周期，而不是等它自己结束
90% 的泄漏本质是“没有退出机制”。写 for {} 或 for range ch 却不检查 ctx.Done()，等于埋雷。
- 永远用
context.WithCancel或context.WithTimeout创建子 context，并确保在合适时机调用cancel()——忘记调用，等于没加 - 对 channel 操作，优先用
select { case ，而不是裸写 <code> - HTTP handler、定时任务、后台 worker，凡是可能长期存活的 goroutine，都该绑定一个可取消的 context
- 不要依赖“程序退出时 runtime 会清理”——泄漏发生在运行中，用户请求卡住、内存涨爆、连接耗尽，都在那之前
最容易被忽略的是：泄漏往往不是单点 bug，而是多个 goroutine 彼此等待（比如 A 等 B 发 signal，B 等 C 关 channel，C 等 A 先退出），这时候光看单个堆栈看不出闭环，得靠多次 pprof 快照对比 + context 传播路径反推。
