goroutine 泄露的典型表现是程序内存持续上涨、runtime.numgoroutine() 返回值只增不减、pprof 查看 /debug/pprof/goroutine?debug=2 里堆栈长期卡在 channel receive、time.sleep 或 sync.waitgroup.wait；常见诱因包括忘记关闭 channel、select 没写 default 或 case。
goroutine 泄露的典型表现是什么
程序内存持续上涨、runtime.NumGoroutine() 返回值只增不减、pprof 查看 /debug/pprof/goroutine?debug=2 里堆栈长期卡在 channel receive、time.Sleep 或 sync.WaitGroup.Wait —— 这些不是“可能泄露”，基本就是泄露了。
常见诱因：忘记关闭 channel、select 没写 default 或 case 、启动 goroutine 后丢了引用（比如没存到 map 或 slice，也没等它结束）、<code>http.Server 关闭后仍有 handler goroutine 在跑。
用 goleak 检测测试中的 goroutine 泄露
goleak 是最轻量也最可靠的检测手段，但它只在测试阶段起作用，不适用于运行时监控。
- 安装：
go get -u github.com/uber-go/goleak - 在 Test 函数末尾加：
goleak.VerifyNone(t)，它会检查 test 结束后是否还有非系统 goroutine 残留 - 默认忽略标准库启动的 goroutine（如
net/http的监听协程），但如果你手动启了http.Server，得显式忽略：goleak.IgnoreCurrent()或用goleak.Option过滤掉已知安全的堆栈 - 注意：
goleak.VerifyNone(t)必须放在 defer 里，否则 test panic 时不会执行，漏检
修复 channel 相关 goroutine 泄露的三个关键点
90% 的泄露来自 channel 使用不当。核心原则是：谁创建 channel，谁 close；谁接收，谁负责退出条件；谁启动 goroutine，谁确保它能结束。
立即学习“go语言免费学习笔记（深入）”；
- 不要对 nil channel 执行
close()，会 panic；也不要重复 close，会 panic - 向已 close 的 channel 发送数据会 panic，但接收仍可继续，直到读完缓冲区 + 收到零值
- 用
for range ch接收时，必须由发送方 close；如果发送方不确定何时结束，改用select+donechannel 控制生命周期 - 示例错误写法：
go func() { for range ch { /* 处理 */ } }()—— 如果ch永远不 close，这个 goroutine 就永远挂起 - 正确做法：
go func(done
为什么 pprof + 手动分析有时比 goleak 更有用
goleak 告诉你“有泄露”，但不告诉你“在哪漏”。线上或集成测试中无法用 goleak 时，pprof 是唯一可靠入口。
- 触发方式：
curl "http://localhost:6060/debug/pprof/goroutine?debug=2"，重点关注堆栈末尾停在chan receive、semacquire、time.Sleep的 goroutine - 注意区分：
runtime.gopark是正常休眠，但若调用栈上层是你自己的函数（比如myPackage.processLoop），那就是你的逻辑没设退出路径 - 如果看到大量相同堆栈，大概率是某个初始化逻辑被反复执行（比如在 HTTP handler 里每次新建 goroutine 却没控制并发数）
- 一个容易被忽略的点：
context.WithTimeout创建的子 context，如果父 context 已 cancel，子 context 不会自动 propagate 到所有 goroutine —— 你得在每个 goroutine 内部监听ctx.Done()
真正难的不是发现泄露，而是确认「哪个 goroutine 本该结束却没结束」—— 这需要把启动点、退出条件、channel 生命周期三者对齐，缺一不可。
