最轻量的 goroutine 泄漏检测方式是 runtime.NumGoroutine()，通过操作前后计数差值判断是否回归基线，需显式等待 goroutine 退出并多次采样取最小值以避免误报。
用 runtime.NumGoroutine() 在测试里快速抓明显泄漏
这是最轻量、也最容易上手的检测方式，适合在单元测试或 CI 阶段第一时间拦截低级泄漏。它不依赖外部服务，只靠一个计数差值就能发出警报。
关键不是看绝对值，而是看「操作前后是否回归基线」：启动函数 → 给足够时间让 goroutine 退出 → 检查数量是否回落。
- 别只
time.Sleep(100 * time.Millisecond)：有些 goroutine 依赖超时或外部信号（如context.WithTimeout或time.AfterFunc），100ms 可能根本不够；建议配合done chan struct{}显式等待退出 - 系统 goroutine 本身有波动（GC、timer、netpoll 等），单次采样易误报；推荐采样 3 次取最小值作 baseline，或直接用
goleak库自动过滤已知安全 goroutine - 示例中漏掉
close(ch)或没 sender 却，这种写法一跑就漏，NumGoroutine()能立刻暴露
用 net/http/pprof 查生产环境里卡在哪一行
runtime.NumGoroutine() 告诉你“有泄漏”，pprof 才告诉你“谁卡着、为什么卡、从哪来的”。这是线上服务的标准排查路径。
只需两步：导入 _ "net/http/pprof"，再起个独立监听 goroutine（端口建议固定为 :6060）；无需改业务逻辑，零侵入。
立即学习“go语言免费学习笔记（深入）”；
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=1看当前所有 goroutine 的堆栈；加?debug=2还能看到更详细的 channel blocking 信息 - 重点关注状态为
chan receive、select、semacquire或长时间sleep的 goroutine —— 它们大概率就是泄漏源 - 对比两次快照：服务刚启动时抓一次（A），运行 5 分钟后再抓一次（B），用
diff -u A B | grep "^+"找新增堆栈，直指问题函数
用 uber-go/goleak 在测试阶段自动报错
手动数 goroutine 容易漏、难复现、还费时间。goleak 是 Uber 开源的专用检测库，能在测试结束时自动扫描未回收 goroutine，并打印初始调用栈，开发阶段就能堵住大部分泄漏。
- 在
TestMain中调用goleak.VerifyNone(t)，它会自动忽略 runtime 内部 goroutine（比如 timerproc、gcworker），只报你代码里漏掉的 - 它比
NumGoroutine()更准：不依赖 sleep，不被系统波动干扰，还能定位到 goroutine 启动的原始位置 - 注意：必须确保被测逻辑真正“结束”了——比如 HTTP handler 测试要等 response 写完、channel 操作要 close 或 drain 完，否则
goleak会误报
用 context.Context 从源头避免泄漏
绝大多数 goroutine 泄漏，本质是“没有退出机制”。而 context 是 Go 官方提供的、最自然的取消信号传递方式，尤其适合 HTTP 请求、定时任务、长连接等场景。
- 永远不要写
for { select { case 这种无限循环，除非你明确知道它何时停；应改成for { select { case - 启动 goroutine 时，把
ctx作为第一个参数传入，而不是靠全局变量或闭包捕获；这样 cancel 信号才能穿透到底层 - 常见坑：忘了
defer cancel()、在子 goroutine 里没检查ctx.Err()、用context.Background()代替context.WithTimeout导致无法超时退出
真正难排查的泄漏，往往藏在“看起来会自己结束”的地方：比如一个被遗忘的 time.Ticker 没 Stop()，或者一个 HTTP client 的 Transport 里残留了 idle connection goroutine。这些不会被 NumGoroutine() 立刻发现，但 pprof 快照对比和 goleak 的调用栈追踪能揪出来。动手前先想清楚：这个 goroutine，谁负责关？怎么关？关得掉吗？
