每个启动的goroutine都必须有明确的退出路径。通过runtime.NumGoroutine()监控数量增长和pprof分析调用栈可发现泄漏；常见原因为channel阻塞、context未取消、无限循环无退出、WaitGroup使用不当，应结合context控制生命周期、设置超时、关闭channel、正确调用Done并测试时断言goroutine数。
Go 程序中的 Goroutine 泄漏是常见但容易被忽视的问题。它不会立即报错，而是让程序缓慢“窒息”——占用的资源越来越多，最终可能导致服务变慢甚至崩溃。核心思路就是：**每个启动的 goroutine 都必须有明确的退出路径**。下面从排查和防止两个方面说明实用方法。
如何发现 Goroutine 泄漏
在问题影响线上服务前，最好能通过监控或工具提前察觉。
- 使用 runtime.NumGoroutine() 监控数量：这是最直接的方法。在服务的关键入口（如 HTTP 处理函数）前后打印当前 goroutine 的数量。如果请求处理完毕后，总数持续增长且不回落，基本可以确定存在泄漏。- 集成 pprof 进行深度分析：在程序中引入 net/http/pprof 包，它会自动注册调试路由。
启动一个 HTTP 服务暴露指标：
import _ "net/http/pprof"
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
程序运行时，访问 https://www.php.cn/link/53d7f154d6c0738fa10f9402b2e93e96，点击 goroutine 链接，或者用命令行获取文本信息：
立即学习“go语言免费学习笔记（深入）”；
curl -s https://www.php.cn/link/53d7f154d6c0738fa10f9402b2e93e96goroutine?debug=2
这个输出会列出所有正在运行的 goroutine 及其调用栈。重点关注那些数量庞大、状态为 “IO wait” 或 “chan receive”、“chan send” 的 goroutine，它们很可能就是泄漏点。
常见泄漏原因与避免方法
知道了怎么查，更要明白为什么会出现泄漏。以下是几种典型场景及应对方案。
- channel 阻塞导致泄漏：这是最常见的原因。比如一个 goroutine 在从一个无缓冲 channel 接收数据，但发送方因为逻辑错误或提前退出未能发送，这个接收者就会永远阻塞。解决方法是：- 为 channel 设置缓冲区，避免发送/接收瞬间阻塞。
- 使用 context 控制超时或取消，避免无限等待。
- 确保不再使用的 channel 调用 close()，已关闭的 channel 接收操作会立刻返回零值。
- 无限循环未设退出条件：goroutine 中的 for 循环如果没有结合 select 和 context.Done() 来监听退出信号，就会成为“永生”协程。正确的做法是在循环内部检查 ctx 是否已完成。
- WaitGroup 使用不当：使用 sync.WaitGroup 等待一组 goroutine 完成时，必须保证每个 goroutine 都调用了 wg.Done()。如果某个 goroutine 因为 panic 或逻辑跳过而未调用，wg.Wait() 就会永久阻塞，也可能间接导致泄漏。
编写防泄漏的代码习惯
预防胜于治疗。养成良好的编码习惯能大幅降低泄漏风险。
- 始终考虑生命周期：每当写下 go func()，立刻问自己：这个 goroutine 怎么停下来？是任务完成自然退出，还是需要外部通知？退出路径必须清晰。- 优先使用 context 传递控制信号：对于任何可能长时间运行或需要中断的操作，将 context.Context 作为第一个参数传入。利用它来统一管理超时、取消和截止时间。
- 测试时加入 goroutine 计数断言：在单元测试中，可以在测试前后调用 runtime.NumGoroutine()，确保数量没有异常增加。这能帮你捕获测试本身引发的泄漏。
基本上就这些。Goroutine 泄漏不复杂但容易忽略，关键是建立监控意识和编写有“终点”的并发代码。用好 pprof 和 context，大部分问题都能有效规避。
