goroutine泄露典型现象是内存持续上涨、NumGoroutine只增不减、pprof显示大量挂起在select/chan/semacquire的goroutine、测试后进程不退出；goleak需显式defer VerifyNone，避免init启动goroutine，优先用IgnoreCurrent而非IgnoreTopFunction，CI中需设timeout并确保资源清理后校验。
goroutine 泄露的典型现象是什么
程序运行时间越长，内存占用持续上涨，runtime.NumGoroutine() 返回值只增不减；pprof 查看 /debug/pprof/goroutine?debug=2 时发现大量处于 select、chan receive 或 semacquire 状态的 goroutine 长期挂起；测试用例跑完后进程不退出，或 go test 报超时。
用 goleak 检测泄露的实操要点
goleak 是最轻量且被官方 test 包间接推荐的方案，但它不是“加个 import 就自动生效”——必须显式在测试结束前调用检查逻辑。
- 在
TestXxx函数末尾加：func TestSomething(t *testing.T) { defer goleak.VerifyNone(t) // ... your test code } - 不要在
init()或包级变量中触发 goroutine，否则VerifyNone会把它们当成泄露（它默认忽略标准库启动的 goroutine，但不忽略你提前拉起的） - 如果测试本身合法启用了后台 goroutine（比如启动 HTTP server），要用
goleak.IgnoreCurrent()或指定过滤器：defer goleak.VerifyNone(t, goleak.IgnoreCurrent())
- 注意：goleak 默认只检查测试函数执行期间新增的 goroutine，不扫描整个进程生命周期；若想覆盖更广，需配合
goleak.Cleanup()和自定义选项
为什么 goleak.IgnoreTopFunction 不总管用
这个函数本意是忽略某条调用栈顶的 goroutine，但实际容易失效——因为 goroutine 启动点可能被编译器内联，或栈帧顺序受调度影响而波动。常见误用：goleak.IgnoreTopFunction("myapp.(*Server).start")，结果仍报泄露。
- 优先用
IgnoreCurrent()替代硬编码函数名，尤其适用于测试中临时启的 goroutine - 若必须按函数过滤，确保目标函数未被内联（加
//go:noinline注释） - 更可靠的方式是结合
goroutine.GoroutineID()+ 自定义断言，但 goleak 不暴露 ID；此时建议退回到手动快照比对：before := runtime.NumGoroutine() // ... do work after := runtime.NumGoroutine() if after > before { t.Errorf("goroutine leak: %d → %d", before, after) }
集成到 CI 的关键细节
本地跑通不等于 CI 安全——并发环境、超时设置、依赖初始化顺序都可能导致漏检。
立即学习“go语言免费学习笔记（深入）”；
- CI 中务必设置
-timeout（如go test -timeout 30s），否则泄露 goroutine 可能拖垮整个 job - 避免在
TestMain里全局启用 goleak，它会干扰子测试的独立性；每个测试单独 defer 更稳妥 - 某些依赖（如
sql.DB、http.Server）会在 Close 后异步清理 goroutine，但有延迟；测试中调用Close()后应加短 sleep 或重试等待，再触发VerifyNone - goleak 对 Go 1.21+ 的新调度器行为兼容良好，但若用旧版 Go（
