用 pprof 抓泄漏 goroutine：启动 net/http/pprof，访问 /debug/pprof/goroutine?debug=2 查完整堆栈；无 HTTP 时用 runtime/pprof.Lookup("goroutine").WriteTo(os.Stdout, 2)；注意 ?debug=2 才显示详细调用链，避免只看默认统计页。
Go 程序跑着跑着内存涨不停，pprof 怎么抓到泄漏的 goroutine？
内存持续上涨不回落，八成是 goroutine 没退出、还挂着数据引用。这时候别急着改逻辑，先用 pprof 看实时 goroutine 堆栈——它不看内存分配，专盯“活着但不该活”的协程。
关键操作：启动时加 net/http/pprof，比如在 main() 里加 http.ListenAndServe(":6060", nil)，然后访问 http://localhost:6060/debug/pprof/goroutine?debug=2。这个 ?debug=2 很重要，它输出完整堆栈，否则只看到摘要。
- 别只看
/goroutine默认页（?debug=1），那只是统计数，看不出谁卡在哪 - 如果程序没开 HTTP server，用
runtime/pprof.Lookup("goroutine").WriteTo(os.Stdout, 2)手动 dump，注意第二个参数必须是2 - 常见陷阱：日志打太勤、
time.AfterFunc传了闭包却没清引用、select漏写default导致永久阻塞
Goleak 测试里报 found unexpected goroutines 怎么定位？
Goleak 是单元测试阶段的守门员，它不查运行时内存，只检查测试前后 goroutine 数量是否“净增”。报错说明有 goroutine 没被正确清理，通常发生在异步初始化、后台 ticker、或未关闭的 channel 上。
典型场景：测试里启了个 time.Ticker，忘了 ticker.Stop()；或者用 go func() { ... }() 启了个临时协程，但里面调了 time.Sleep 或等外部信号，测试结束时它还在跑。
立即学习“go语言免费学习笔记（深入）”；
- 加
goleak.IgnoreTopFunction("testing.(*T).Run")没用——这是忽略测试框架自身，不是你的代码 - 真正要 ignore 的是已知“合法残留”，比如某些库的全局监控 goroutine，得用
goleak.IgnoreCurrent()在测试开头拍个快照，或明确 ignore 函数名如goleak.IgnoreTopFunction("github.com/some/pkg.initBackgroundWorker") - 测试函数末尾加
defer goleak.VerifyNone(t)，比在每个TestXxx里重复写更稳妥
为什么 pprof 显示 goroutine 很多，但 heap 却没涨？
goroutine 本身开销小（初始栈 2KB），但只要它活着，就可能持有着大对象指针——比如一个闭包捕获了整个 struct，而 struct 里有 []byte 或 map。这时 pprof heap 看不到“泄漏源头”，因为内存是被活跃 goroutine “钉住”了，GC 不敢回收。
验证方法：对比 /debug/pprof/goroutine?debug=2 和 /debug/pprof/heap?gc=1（强制 GC 后采样）。如果后者没变但前者堆栈里反复出现同一段代码，基本就是它在 hold 住内存。
- 不要依赖
runtime.ReadMemStats的NumGoroutine判断泄漏——数量稳定不代表安全，可能全是“僵尸协程”，空转但不退出 -
pprof trace对这种问题帮助有限，它侧重执行路径和阻塞事件，不如直接看 goroutine 堆栈来得直白 - 生产环境慎用
?debug=2，大量 goroutine 时响应会卡，建议先用?debug=1筛出数量异常的类型，再针对性抓
用 pprof 和 Goleak 联合排查时，最容易漏掉什么？
最常被跳过的，是“goroutine 生命周期和所属上下文不匹配”。比如在 HTTP handler 里起 goroutine 处理耗时任务，但 handler 返回后，goroutine 还在跑，且引用了 *http.Request 或 context.Context——这不仅导致泄漏，还可能引发 panic（request.Body 已关闭）。
另一个隐形坑：第三方库内部启的 goroutine，你没显式控制权，但它的行为受你传入参数影响。例如用 redis.Client 的 Pipeline 时传了带 cancel 的 context，但没在 pipeline 结束后调用 Close()，底层 watchdog goroutine 就可能滞留。
- 所有
go func()必须配对考虑退出机制：channel 关闭、context Done、显式 flag 控制 -
Goleak默认不检测 test helper 函数里的 goroutine，如果你把go写在setupXXX()里，它不会自动关联到当前 test，得手动管理 - pprof 的 goroutine profile 是瞬时快照，一次抓不到别放弃，用脚本轮询
curl -s http://localhost:6060/debug/pprof/goroutine?debug=2 | grep -A5 "YourFuncName"看是否持续存在
