goroutine泄漏典型表现为内存持续上涨、pprof显示大量runtime.gopark状态goroutine、http响应变慢但cpu不高；本质是goroutine因阻塞或逻辑缺陷无法退出。
goroutine 泄漏的典型表现是什么
程序内存持续上涨、pprof 查到大量 runtime.gopark 状态的 goroutine、HTTP 服务响应变慢但 CPU 不高，基本可以锁定是泄漏。本质是 goroutine 启动后因阻塞（如 channel 读写、锁等待、time.Sleep）或逻辑缺陷（比如忘了 close channel、select 没 default 分支）永远无法退出。
- 常见错误现象：
net/http.(*conn).serve卡在read、select永远不走 default、for range ch遇到未关闭的 channel 一直挂起 - 使用场景：HTTP handler 启 goroutine 处理异步任务、worker pool 中 worker 从 channel 取任务但没做退出控制、定时器未 stop
- 性能影响：每个 goroutine 至少占用 2KB 栈空间，上万 goroutine 就是几十 MB 内存，且调度开销剧增
用 pprof 快速定位泄漏 goroutine
别猜，直接看运行时数据。启动时加 http://localhost:6060/debug/pprof/goroutine?debug=2 能看到完整堆栈，比 ?debug=1 更有用。
- 执行
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2进入交互式分析 - 输入
top查数量最多的 goroutine 类型，重点关注非runtime.开头的用户代码位置 - 对比两次快照：用
go tool pprof -http=:8080启服务，隔 30 秒分别抓取，再用diff -d看新增 goroutine - 容易踩的坑：没开
GOROOT/src/runtime/proc.go的调试符号、生产环境忘了加net/http/pprof导入
channel 关闭和 select 的常见误用
goroutine 泄漏最多发生在 channel 和 select 组合里——不是 channel 没关，就是 select 没兜底。
-
for range ch会一直等，除非ch被close()；如果 sender 忘了 close，receiver 就卡死 -
select里只有case 没 <code>default:或case ，一旦 channel 暂时无数据，goroutine 就挂起 - 向已关闭的 channel 发送数据会 panic，但接收是安全的（返回零值 + false），这点常被误判为“还能读”
- 正确做法：sender 负责 close；receiver 用
ctx控制生命周期；所有阻塞操作都应有超时或取消路径 - 示例：
go func() { for { select { case job := <-jobs: handle(job) case <-ctx.Done(): // 必须有 return } } }()
HTTP handler 中启动 goroutine 的安全姿势
很多人在 handler 里直接 go doSomething()，结果请求结束、response 写完，goroutine 还在跑，还可能访问已释放的 request context 或局部变量。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
go process(r.Body)——r.Body在 handler 返回后可能被关闭，goroutine 读取会出错 - 正确思路：把需要的数据拷贝进去，用独立 context 控制生命周期，避免引用外部 request/response
- 必须检查：是否用了
r.Context()？如果是，要ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)，而不是直接传原 ctx - 更稳妥的做法：用带缓冲的 channel + 固定 worker 数量，而不是每个请求启一个 goroutine
- 容易忽略的点：log 输出、defer 清理、panic recover 都得在 goroutine 内部做，不能依赖外层 handler 的 defer
goroutine 泄漏最难 debug 的地方，往往不在启动点，而在它所依赖的 channel、timer、context 或第三方库调用的阻塞点——你得顺着栈一层层看谁没返回，而不是只盯着 go func() 那一行。
