快速定位 goroutine 泄漏需先用 runtime.NumGoroutine() 监控增长，再通过 pprof/goroutine?debug=2 查看阻塞在 select{}、chan recv 或 sync.WaitGroup.Wait 的栈；常见原因包括漏调 wg.Done()、向已关闭 channel 发送、for 循环中未 stop time.After 创建的 timer。
goroutine 泄漏怎么快速定位
运行时 goroutine 数量持续增长，通常是泄漏的典型信号。别急着看业务逻辑，先用 runtime.NumGoroutine() 打点日志或暴露 HTTP 指标，确认是否真在涨。更直接的是用 pprof：
curl -s http://localhost:6060/debug/pprof/goroutine?debug=2，加
?debug=2 能看到完整调用栈，重点找那些卡在 select{}、chan recv 或 sync.WaitGroup.Wait 的 goroutine。
常见陷阱：
- 忘记调用
wg.Done()（尤其在 error 分支里） - 向已关闭的 channel 发送数据导致永久阻塞
- 使用
time.After在 for 循环里反复创建 timer，却不 stop
竞态条件（race condition）必须开 -race 编译
Go 的 -race 检测器不是可选项，是并发调试的底线。它会在运行时捕获读写冲突，输出类似这样的报告：
WARNING: DATA RACE
Write at 0x00c00001a080 by goroutine 7:
main.main.func1()
/tmp/main.go:12 +0x39
Previous read at 0x00c00001a080 by goroutine 6:
main.main.func2()
/tmp/main.go:16 +0x52。注意它只对运行时访问生效，不会检测未执行到的代码路径；而且一旦开启，程序性能下降明显，**仅用于测试环境**。
容易忽略的点：
- struct 字段未加锁，但多个 goroutine 同时读写不同字段——仍可能触发 false positive（因内存对齐重叠）
- map 并发读写必须用
sync.Map或显式锁，-race能抓到，但上线后 panic 更常见
channel 死锁 panic 的真实原因
“fatal error: all goroutines are asleep - deadlock” 不一定代表你写了 select {}，而是所有 goroutine 都卡在 channel 操作上且无其他唤醒路径。典型场景：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 向无缓冲 channel 发送，但没有 goroutine 在接收
- 从已关闭且为空的 channel 接收（会立即返回零值，不阻塞）——这不是死锁，但常被误判
- 用
for range ch遍历一个永远不会关闭的 channel
立即学习“go语言免费学习笔记（深入）”；
调试建议：启动时加 GODEBUG=schedtrace=1000，每秒打印调度器状态，观察 goroutine 是否长期处于 runnable 或 waiting 状态；配合 pprof/goroutine?debug=2 看阻塞点。
调试时慎用 fmt.Println 打印 goroutine ID
fmt.Println 是同步 I/O，本身会抢锁、影响调度，尤其在高并发下可能掩盖或改变竞态行为。想打日志又不想干扰行为，优先用 log 包并设置 log.Lshortfile，或者用 runtime.Caller(1) 获取当前 goroutine 栈帧信息。如果真要区分 goroutine，可以这样轻量标记：
go func(id int) {
log.Printf("[goroutine %d] started", id)
// ...
}(i)，但别用 runtime.Goid()——它不是公开 API，Go 1.22+ 已移除。
真正难缠的问题往往藏在：timer 未 stop、context.WithCancel 后没 cancel、http.Client 的 Transport 复用导致连接池 goroutine 残留——这些不会立刻报错，但压测一阵后资源就悄悄耗尽。
