Go 中 goroutine 泄漏指 goroutine 启动后因阻塞在 select 等操作上而永不终止，并非内存未释放。
Go 里 goroutine 泄漏不是“内存没释放”，而是 goroutine 启动了却永远卡在 select、 或 <code>time.Sleep 上，既不退出也不被回收——它持续占着栈内存和调度资源，积少成多就会拖垮服务。
用 context.Context 控制生命周期，别靠“等它自己结束”
goroutine 泄漏最常见原因：没给退出信号。比如一个后台轮询任务，写成无限循环却不检查是否该停：
go func() {
for { // 没有退出条件 → 泄漏
doWork()
time.Sleep(5 * time.Second)
}
}()正确做法是把 ctx.Done() 塞进 select，并确保上层调用方能主动 cancel()：
-
context.WithCancel或context.WithTimeout创建可取消的上下文 - goroutine 内必须用
select监听ctx.Done()，不能只用default或忽略它 - 务必在启动 goroutine 的作用域里
defer cancel()（或明确调用），否则ctx永远不会关闭 - 如果 goroutine 本身要传参，把
ctx作为第一个参数传入，避免闭包捕获外部变量导致意外引用
别让 goroutine 卡在 channel 上，关通道比“等接收”更可靠
向无接收者的 channel 发送数据、从永不关闭的 channel 接收数据，都会永久阻塞——这是泄漏高发区。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 发送方应使用带缓冲的 channel，或用
select+default防止死锁；更稳妥的是用ctx.Done()配合select - 接收方若依赖 channel 关闭退出，必须由**发送方或协调者**负责
close(ch)，不能指望“没人发就自动停” - 避免在 goroutine 内部单独开一个
for range ch却不控制ch的生命周期——range 只在 channel 关闭后退出 - 不要用
len(ch) == 0判断是否可读，这不可靠；要用select配合default或超时
测试阶段用 runtime.NumGoroutine() + goleak 主动拦截
靠线上报警发现泄漏太晚。单元测试里就要卡住它：
-
runtime.NumGoroutine()是最轻量的探测器，但需注意：系统 goroutine 本身会波动，建议 sleep 后多采样一次，或用time.AfterFunc等待更久 - 直接集成
uber-go/goleak：在TestMain里加goleak.VerifyNone(m)，它会自动扫描测试前后新增且未退出的 goroutine，并打出初始调用栈 - 避免在测试中用
time.Sleep硬等——改用sync.WaitGroup或context.WithTimeout显式等待完成 - HTTP handler 测试时，记得触发
http.Close()或用httptest.NewUnstartedServer控制生命周期
生产环境靠 pprof 快照对比，别只看总数
线上发现 runtime.NumGoroutine() 持续上涨？下一步不是重启，是抓现场：
- 启用
net/http/pprof后访问http://localhost:6060/debug/pprof/goroutine?debug=2，看完整调用栈 - 重点关注状态为
chan receive、select、semacquire且栈帧集中在你代码某几行的 goroutine - 用
go tool pprof下载两个时间点的快照，执行diff -base找出新增 goroutine 的共性栈路径 - 别只信 “goroutine 数量”，要结合
debug.ReadGCStats看NumGoroutine是否与 GC 次数强相关——若 GC 频繁但 goroutine 不降，基本坐实泄漏
真正难防的泄漏，往往藏在“它应该会停”的假设里：比如以为某个 channel 肯定会被关闭，或某个 HTTP 连接肯定会断。实际得靠 context 显式传递取消信号、用 goleak 在 CI 里卡住测试、再用 pprof 快照定位到具体哪一行 select 卡死了——这三步缺一不可。
