Go 程序中 goroutine 泄漏不是“会不会发生”的问题，而是“什么时候被发现”的问题——它往往在压测后内存缓慢上涨、服务重启前卡顿、pprof 里看到几百个 chan receive 状态协程时才浮出水面。
用 runtime.NumGoroutine() 快速验证测试是否泄漏
这是最轻量、最直接的单元测试级检测手段，适合在 CI 或本地开发阶段快速拦截明显泄漏。
- 它返回当前存活的 goroutine 总数（含 runtime 自身维护的，但波动通常很小）
- 关键不是绝对值，而是「操作前后是否回归基线」：启动函数 → 等待合理时间 → 检查数量是否回落
- 别只 sleep 100ms：有些 goroutine 启动后需等待超时或外部事件，建议配合
time.AfterFunc或显式信号（如done chan struct{}）来确认退出 - 避免误报：系统 goroutine 可能因 GC、timer 等临时波动，建议采样 3 次取最小值作 baseline，或使用
goleak库自动过滤已知安全 goroutine
func TestProcessJob(t *testing.T) {
before := runtime.NumGoroutine()
ch := make(chan int, 1)
go func() {
<-ch // 永远阻塞：无发送者，也未 close
}()
// 没有 close(ch)，也没有 sender → 泄漏已发生
time.Sleep(50 * time.Millisecond)
after := runtime.NumGoroutine()
if after > before+2 { // 允许 ±1~2 个浮动
t.Errorf("leak detected: %d → %d", before, after)
}
}用 net/http/pprof 定位阻塞点和调用栈
当服务已上线、goroutine 数持续增长，runtime.NumGoroutine() 只告诉你“有事”，而 pprof 告诉你“什么事、在哪行、为什么卡住”。
- 只需导入
_ "net/http/pprof"，再起一个独立 goroutine 监听:6060，无需改业务逻辑 -
/debug/pprof/goroutine?debug=1显示所有 goroutine 当前堆栈；?debug=2还会显示更全的 blocking channel 信息 - 重点筛选状态为
chan receive、select、semacquire或长时间sleep的 goroutine —— 它们大概率就是泄漏源 - 对比两次快照：服务刚启动时抓一次（A），运行 5 分钟后再抓一次（B），用
diff -u A B | grep "^+"找新增堆栈，直指问题函数
用 context.Context 主动控制 goroutine 生命周期
绝大多数泄漏本质是“没有退出机制”，而 context 是 Go 官方提供的、最自然的取消信号传递方式。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要写
for {}或for range ch而不检查ctx.Done() - 用
context.WithCancel或context.WithTimeout创建子 context，并确保在合适时机调用cancel()—— 忘记调用等于没加 - channel 操作必须与 context 结合：用
select { case ，而不是裸 - 注意：
context.Background()本身不会取消，仅作根节点；真正起作用的是你派生出的、并被显式 cancel 的那个
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() // 关键：确保 cancel 被调用go func(ctx context.Context) { for { select { case <-ctx.Done(): fmt.Println("goroutine exiting gracefully") return default: // do work time.Sleep(100 * time.Millisecond) } } }(ctx)
用 sync.WaitGroup 配合显式关闭确保清理完成
当你需要等一组 goroutine 全部结束（比如服务优雅 shutdown），WaitGroup 是唯一可靠的方式 —— runtime.Gosched() 或 sleep 都不可靠。
-
wg.Add(1)必须在go语句之前，否则存在竞态：goroutine 可能先执行完Done()，导致Wait()永久阻塞 - 每个 goroutine 必须且只能调用一次
wg.Done()，推荐用defer wg.Done()防止遗漏 - 若 goroutine 内部依赖 channel，记得在退出前
close(ch)（如果该 channel 不再被写入），否则其他 goroutine 可能还在等它 - WaitGroup 本身不解决泄漏，但它让“等待结束”这件事变得可预测、可验证 —— 是自动化 shutdown 流程的基石
真正难的不是写对某一行代码，而是所有 goroutine 都得有明确的 exit path，且所有 exit path 都被调用。哪怕一个 defer cancel() 忘了写，或一个 close(ch) 漏在 error 分支里，泄漏就藏进去了。生产环境里，它往往不报错，只悄悄吃掉内存和连接数。
