goleak 检测不到协程泄露主因是未正确使用 leak.ignoretopfunction 或漏调 leak.verifynone(t)；应于每个测试末尾调用 verify，忽略时需精确匹配栈顶函数全名，并用 waitgroup/context 显式管理协程生命周期。
goleak 检测不到协程泄露？检查测试是否调用了 leak.IgnoreTopFunction
goleak 默认只报告「测试结束后仍在运行」的 goroutine，但很多协程会因顶层函数（比如 http.ListenAndServe、time.AfterFunc 或测试中启动的 goroutine 未显式关闭）被误判为“合法残留”。如果你发现明显有泄漏却没报错，大概率是漏掉了 leak.IgnoreTopFunction 的调用，或者它被错误地加在了不该忽略的地方。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只在
TestMain或每个测试函数末尾调用leak.VerifyNone(t)，不要在中间提前 verify - 若需忽略某类协程（如日志轮转、健康检查心跳），用
leak.IgnoreTopFunction("pkg.(*Server).startHeartbeat")，路径必须完全匹配运行时栈顶函数名 - 别用模糊匹配——
leak.IgnoreTopFunction("heartbeat")无效，goleak 不支持子串匹配 - 忽略前先用
leak.Find打印实际泄漏栈，确认函数签名，避免误忽略真实泄漏
测试中启动的 goroutine 没等完就结束，导致 goleak 误报
这是最常见误报来源：测试里用 go fn() 启动协程，但没等它退出就返回，goleak 自然把它当泄漏。本质不是工具问题，而是测试逻辑没覆盖生命周期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.WaitGroup或chan struct{}显式同步，例如：done := make(chan struct{})<br>go func() { defer close(done); work() }()<br><-- 做事 --><br><-done - 避免在测试中直接起长期运行的 goroutine（如
for range ch无退出条件），改用带 context 取消的版本：for { select { case - 如果只是想“触发后不管”，也得给它一个明确出口，比如传入
context.WithTimeout，而不是裸起一个 goroutine
goleak 在 CI 中不报错，本地却报？检查 Go 版本和 runtime 行为差异
goleak 依赖 runtime.Stack 抓取 goroutine 栈，而不同 Go 版本对后台 goroutine（如 timerproc、finalizer、netpoll）的调度和存活时间有细微差别。1.21+ 引入了更激进的 idle goroutine 回收，可能导致本地跑出泄漏、CI 却绕过了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- CI 和本地使用完全一致的 Go 版本（推荐锁死
GOPATH和GOROOT，或用.go-version） - 在 CI 脚本中加一句
go test -v -race ./... 2>&1 | grep -i "leak"，确保 goleak 输出没被静默吞掉 - 禁用 GC 相关干扰：测试前加
debug.SetGCPercent(-1)，避免 GC 动作引发 finalizer goroutine 波动 - 用
go tool trace对比本地和 CI 的 goroutine 生命周期图谱，确认是否真有差异
为什么 leak.VerifyNone(t) 放在 TestMain 里反而漏检？
因为 TestMain 是整个包测试的入口，所有 TestXxx 都在它内部执行。如果只在 TestMain 结束时 verify 一次，那就等于把所有测试的 goroutine 状态混在一起判断——前面测试遗留的泄漏，可能被后面测试“覆盖”掉（比如后者起了同名 goroutine 掩盖了前者栈），最终漏报。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
leak.VerifyNone(t)必须放在每个独立测试函数末尾，或用testify/suite的AfterTest钩子 - 如果坚持用
TestMain，得配合testing.M手动遍历所有测试名称，并在每个子测试 run 完后立即 verify，否则没意义 - 注意
t.Parallel()测试：verify 必须在 parallel block 内部，不能等到外部函数结束
goleak 的核心限制在于它只能看「快照」，没法追踪 goroutine 的创建源头或语义意图。真正难的从来不是加一行 leak.VerifyNone，而是判断哪一行 go 是该等的、哪一行是该忽略的、哪一行其实早该被 context 控制住——这些都得回溯到业务逻辑本身。
