检测goroutine泄漏的核心思路是测试前后统计活跃数量并比对，结合runtime.NumGoroutine()、defer延迟检查、pprof分析及预防常见泄漏模式（如未关闭channel、未取消context等）来识别和修复。
检测 goroutine 泄漏的核心思路是：在测试前后统计活跃 goroutine 数量，若数量持续增长且无法回收，就可能存在泄漏。Golang 本身不提供自动泄漏报告，但可通过 runtime.NumGoroutine() + 测试断言 + 工具辅助来有效识别。
基础方法：手动比对 goroutine 数量
这是最轻量、最直接的检测方式，适合单元测试场景。
- 在测试函数开始前调用
runtime.NumGoroutine()记录初始值 - 执行待测逻辑（尤其是启动 goroutine 的代码）
- 主动触发清理（如关闭 channel、调用
Close()、等待WaitGroup完成等） - 用
time.Sleep短暂等待（如 10–50ms），让 runtime 有机会调度和回收 - 再次获取 goroutine 数量，与初始值比较；差值应为 0（或可预期的固定增量）
增强版：封装可复用的泄漏检测辅助函数
避免重复写 sleep 和断言，可封装一个通用检测器：
func TestMyConcurrentFunc(t *testing.T) {
start := runtime.NumGoroutine()
defer func() {
// 给 runtime 留出回收时间
time.Sleep(10 * time.Millisecond)
if runtime.NumGoroutine() > start {
t.Errorf("goroutine leak: %d → %d", start, runtime.NumGoroutine())
}
}()
// 调用你的并发函数，例如：
MyConcurrentFunc()
}
注意：defer 中的 sleep 和检查必须放在测试逻辑之后，否则会提前执行。
立即学习“go语言免费学习笔记（深入）”；
进阶手段：pprof + net/http/pprof 实时观察
当手动计数难以定位源头时，启用 pprof 可查看当前所有 goroutine 的堆栈：
- 在测试程序中导入
_ "net/http/pprof"并启动 HTTP server（如go http.ListenAndServe("localhost:6060", nil)） - 测试运行中访问
http://localhost:6060/debug/pprof/goroutine?debug=2，获取完整 goroutine 列表及阻塞位置 - 重点关注状态为
IO wait、chan receive、select或长时间sleep的 goroutine —— 它们很可能卡在未关闭的 channel、无缓冲 channel 发送、或缺少context取消上
预防性实践：常见泄漏模式与修复建议
多数 goroutine 泄漏源于“启动了却忘了收尾”。高频场景包括：
- 无缓冲 channel 发送未被接收：发送方 goroutine 永久阻塞。解法：改用带缓冲 channel，或确保接收方必然运行（加超时、用 select + default）
-
忘记 close channel 或 cancel context：监听
ctx.Done()的 goroutine 不会退出。解法：始终在合适时机调用cancel()，或用defer cancel() -
goroutine 启动后 panic 未 recover，且无同步等待机制：导致主流程结束但子 goroutine 仍在跑。解法：用
WaitGroup显式等待，或通过 channel 收集完成信号 -
定时器/心跳 goroutine 缺少退出控制：如
time.Tick配合无限 for 循环。解法：改用time.NewTicker+select { case
基本上就这些。不需要复杂工具也能发现大部分泄漏，关键是养成“启动必有回收”的编码习惯，并在测试中加入 goroutine 数量断言。
