goleak 和 pprof 需手动集成才能生效：goleak 必须通过 defer goleak.verifynone(t) 或 testmain 中 goleak.verifytestmain(m) 显式启用；pprof 需启动 http 服务或调用 runtime/pprof.writeto，且 ?debug=2 才显示完整堆栈；泄漏确认需交叉验证 goroutine 数量与 heap 分析，而非仅看内存增长。
装完 Go 环境后，goleak 和 pprof 不是开箱即用的“检测开关”，必须手动集成到测试流程或运行时服务中，否则它们压根不会触发检查。
goleak 必须显式注入测试生命周期
goleak 不会自动扫描你的代码；它只在测试结束时比对 goroutine 数量。没加 defer goleak.VerifyNone(t) 或没配 TestMain，就等于没装。
- 单个测试函数里最稳妥：在
func TestXxx(t *testing.T)开头加defer goleak.VerifyNone(t)—— 这能捕获该测试内启动但未退出的 goroutine - 包级统一管控：写一个
func TestMain(m *testing.M)，里面调用goleak.VerifyTestMain(m)—— 它会在所有测试跑完后做一次终检，适合查跨测试残留（比如全局 ticker） - 并行测试（
t.Parallel()）容易误报：因为 goroutine 可能还在跑，但测试已标记完成。此时必须用VerifyTestMain，不能依赖单个VerifyNone - 忽略已知合法 goroutine：用
goleak.IgnoreCurrent()在测试开头拍快照，或用goleak.IgnoreTopFunction("github.com/xxx/pkg.startWorker")显式排除第三方后台协程
pprof 需要主动暴露端点或手动 dump
net/http/pprof 不是默认开启的服务，导入包只是注册路由，你还得真正启动 HTTP server；没有 http.ListenAndServe，/debug/pprof/goroutine?debug=2 根本访问不到。
- HTTP 服务场景：导入
_ "net/http/pprof"后，在main()里起一个 goroutine 跑http.ListenAndServe(":6060", nil)—— 注意端口别被占用 - 命令行工具或无 HTTP 场景：用
runtime/pprof.Lookup("goroutine").WriteTo(os.Stdout, 2)，第二个参数必须是2，否则只输出统计摘要，看不到阻塞堆栈 -
?debug=2是关键：它显示完整调用链和阻塞时长，比如看到432000s（5 天），基本就是泄漏了；?debug=1只有数字，没用 - Go 1.24+ 新增
/goroutineleak端点，但需先设环境变量GODEBUG=goleak=1并手动触发一次runtime.GC()才生效，不是拿来就用
泄漏确认不能只看内存，要交叉验证 goroutine 数量
内存涨 ≠ 内存泄漏；goroutine 不回落才是 goroutine 泄漏的铁证。很多开发者一看到 heap 上涨就猛抓 pprof heap，结果发现对象分配正常，根源其实在 goroutine 持有引用没释放。
- 先盯
runtime.NumGoroutine()：压测前后、请求处理完后等 30 秒，数字是否回落？持续上升就是泄漏信号 - 再查
/debug/pprof/goroutine?debug=2：重点找卡在chan receive、select、io.ReadFull、net.Conn.Read的 goroutine - 对比
/debug/pprof/heap：如果 heap 中大对象（如[]byte、map）的存活数与泄漏 goroutine 数量趋势一致，大概率是后者“钉住”了前者 - 别信
go vet：它不查运行时 goroutine 状态，对泄漏无感知；goleak和pprof才是真守门员
最常被跳过的一步是：没确认 goleak 是否真的在跑 —— 比如忘了在 TestMain 里调 m.Run()，或者 VerifyTestMain 被包在条件判断里根本没执行。工具集成不是复制粘贴完就结束，得跑一个必泄测试（比如启个没 stop 的 time.Ticker）来验证检测链路是否通畅。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
