goleak.FindLeaks() 检测失败但程序卡死，主因是测试函数提前退出致后台 goroutine 未结束；需用 t.Cleanup、context.WithTimeout 显式关闭，并避免 defer 被跳过。
goleak.FindLeaks() 检测失败但程序明显卡死？检查测试是否提前退出
很多情况下 goleak.FindLeaks() 返回空切片，却观察到 goroutine 数持续上涨、HTTP 超时或 time.Sleep 不生效——根本原因常是测试函数本身没等 goroutine 结束就返回了。
- 测试中启动的 goroutine（比如
go http.ListenAndServe(...)或go worker()）必须显式关闭或超时退出，否则goleak无法捕获“泄漏”，因为泄漏发生在测试生命周期之外 - 用
t.Cleanup()注册关闭逻辑，而不是只靠 defer：defer 在函数 return 后才执行，而测试框架可能在 assert 失败后直接终止，跳过 defer - 给后台 goroutine 加
context.WithTimeout，避免无限等待；例如启动 HTTP server 时传入带 cancel 的context.Context
为什么 goleak.VerifyNone() 在 main 包里报错 “no test context”？
goleak.VerifyNone() 是专为 testing.T 设计的断言函数，不能在普通 main() 或 init 中调用——它依赖测试框架注入的钩子来获取 goroutine 快照。
- 想在非测试环境做粗略检测？改用
goleak.FindLeaks()手动采集两次快照对比，例如启动前调一次，关键操作后再调一次 - 若坚持用
VerifyNone，必须包裹在func TestXxx(t *testing.T)中，且确保所有被测代码路径都走完、资源释放完毕再调用 - 注意：
VerifyNone默认忽略标准库的“已知安全” goroutine（如runtime/pprof相关），但自定义的定时器、net/http server、log/slog.Handler 启动的 goroutine 不在此列
goroutine 泄漏复现不稳定？重点盯住 time.After / time.Tick 和 sync.WaitGroup 使用
最常触发间歇性泄漏的是未被消费的 time.After() 和误用 sync.WaitGroup ——它们不会报错，但会让 goroutine 卡在 channel receive 或 wg.Wait() 上。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
time.After(5 * time.Second)创建的 timer goroutine，在接收者没读取 channel 前永不退出；若 channel 被丢弃（比如 select 中 default 分支提前返回），timer 就泄漏了 -
sync.WaitGroup.Add()和Done()必须严格配对；常见错误是在循环中 Add(1) 但某次迭代 panic 导致 Done() 没执行，后续wg.Wait()永远阻塞 - 用
go tool trace配合goleak：先跑出泄漏现场，生成 trace 文件，用浏览器打开后筛选 “Goroutines” 视图，直接看到哪些 goroutine 处于chan receive或semacquire状态
CI 环境下 goleak 检测总失败，但本地正常？关注日志输出和并发干扰
CI 环境更敏感，常见干扰源是全局 logger、pprof handler、第三方 SDK 自启的健康检查 goroutine ——它们在本地开发时可能被忽略，但在 CI 的纯净环境中暴露出来。
立即学习“go语言免费学习笔记（深入）”；
- 用
goleak.IgnoreTopFunction()过滤确定无害的调用栈，例如"net/http.(*Server).Serve"或"github.com/sirupsen/logrus.(*Entry).fireHooks"，但别盲目 ignoreruntime.goexit下的未知函数 - 确保测试间完全隔离：每个 test case 启动独立的 HTTP server 端口、独立的 DB 连接池、不复用全局 client 实例
- 加
goleak.OptionVerbose(true)输出详细泄漏 goroutine 栈，CI 日志里直接搜goroutine 1234 [chan receive]定位源头
真正难缠的泄漏往往藏在第三方库的回调注册、context 取消传播断裂、或者 defer 里 recover 吞掉 panic 导致 cleanup 逻辑失效——这些地方没有明显报错，但 goleak.FindLeaks() 会忠实列出每一行可疑的 goroutine 起始点。
