goroutine泄露典型表现为内存持续上涨、pprof显示大量runtime.gopark状态goroutine、http响应变慢但cpu不高；主因是未监听ctx.done()导致goroutine卡在select或time.sleep中无法退出。
goroutine 泄露的典型表现是什么
程序内存持续上涨、pprof 查到大量 runtime.gopark 状态的 goroutine、HTTP 服务响应变慢但 CPU 不高——这些往往不是负载问题，而是 goroutine 没被正确回收。最常见的是：启动了 goroutine 去做 I/O 或等待信号，但没监听 ctx.Done()，导致它永远卡在 select 或 time.Sleep 里。
用 context.WithCancel 启动 goroutine 的标准写法
关键不是“加 context”，而是让 goroutine 主动响应取消信号。下面这种写法是错的：
go func() {
time.Sleep(5 * time.Second) // 不检查 ctx，cancel 了也停不下来
doWork()
}()正确做法是把阻塞操作放进 select，并始终包含 ctx.Done() 分支：
- 所有 I/O 调用（如
http.Client.Do、net.Conn.Read）优先传入带 timeout 的context.Context，而不是自己 sleep + retry - 自定义等待逻辑必须用
select包裹，且case 是必选项，不能只 log - 如果 goroutine 内部调用了第三方库（比如数据库驱动），确认它是否接受
context.Context参数；不支持的库要手动包装超时逻辑
为什么 context.WithTimeout 和 context.WithCancel 行为不同
两者都产生可取消的 context，但触发时机和用途有实质差异：
立即学习“go语言免费学习笔记（深入）”；
-
context.WithCancel：需要你显式调用返回的cancel()函数，适合“外部主动终止”场景，比如 HTTP handler 中用户断连 -
context.WithTimeout：内部自动启动一个 timer，到点自动调用cancel()，适合“最长执行时间”约束，比如 RPC 调用不能超过 2s - 别混用：
context.WithTimeout(parent, 0)不等于立即取消，它等价于context.WithCancel；而context.Background().WithDeadline(...)是非法的，必须用context.WithDeadline
容易被忽略的 goroutine 泄露点
很多泄露不是出在主流程，而是边缘 case 或封装过深的地方：
- defer 里启动 goroutine（比如日志上报、指标打点），但没传 context，也没做 done channel 判断
- channel 操作未配对：向无缓冲 channel 发送数据前没确保有人接收，或从已关闭 channel 读取时没处理
ok==false就继续循环 - 使用
sync.WaitGroup等待 goroutine 结束，但忘记wg.Add(1)或wg.Done()，导致wg.Wait()永远阻塞 - HTTP handler 中启 goroutine 处理耗时任务，却把
http.ResponseWriter或request.Body闭包进去——连接断开后 response 已失效，但 goroutine 还在试图写它
真正难排查的泄露，往往藏在第三层依赖的 callback 里，或者超时后仍持有资源的 defer 函数中。
