这是 go 程序已彻底卡死的明确信号，因所有 goroutine 陷入相互等待；必查 channel 收发不匹配、锁未释放或 goroutine 泄漏，如无缓冲 channel 直接发送而无人接收。
看到 fatal error: all goroutines are asleep - deadlock! 就该立刻停手
这不是警告，是 Go 运行时在告诉你：程序已彻底卡死，所有 goroutine 都在等别人先动，没人能推进。它只在“全局阻塞”时触发，所以一旦出现，问题一定在 channel 收发配对、锁持有或 goroutine 生命周期上。
- 最常见诱因：
ch := make(chan int)后直接ch ，而没启动接收方——无缓冲 channel 要求收发双方“同时就位”，缺一不可 - 另一个高危场景：多个 goroutine 共用一个 channel，但关闭逻辑分散，比如 A 发完数据 close(ch)，B 却还在往里 send，会 panic；更隐蔽的是 C 忘关，导致 range 永远等不到 EOF
- 别依赖日志“猜”谁在等——panic 输出里会列出所有 goroutine 的当前堆栈，重点看
main停在哪一行（比如ch 或 <code>mu.Lock()），再扫一眼其他 goroutine 是否全卡在同个 channel 或同一把 mutex 上
select + default 不是万能解药，但能帮你绕过盲等陷阱
很多死锁不是设计错误，而是“不确定对方是否就绪”时硬等造成的。比如启动一个 goroutine 写 channel，主 goroutine 立即 ，但 writer 还没调度到——无缓冲 channel 下这就是死锁起点。
-
select加default可避免永久阻塞，但它只是“不卡住”，不是“解决了通信逻辑”。例如：select { case v, ok := ，这适合轮询或降级逻辑，不适合必须拿到结果的路径 - 对带缓冲 channel，
len(ch) == 0和len(ch) == cap(ch)可辅助判断空满，但对无缓冲 channel 完全无效——它的长度永远是 0，不能用来预测是否可读/可写 - 真正安全的做法是：明确谁发、谁收、谁关。用
sync.WaitGroup控制 sender 完成后由唯一 goroutineclose(ch)，receiver 用for v := range ch或v, ok := 主动感知关闭
mutex 死锁不会报 deadlock!，但卡得更静音
channel 死锁有 panic 报错，mutex 死锁却只会让 goroutine 静默停在 sync.(*Mutex).Lock，连运行时都检测不到——因为它不违反“所有 goroutine 都在等”的条件，只是某个 goroutine 拿着锁不放，别人干等。
- 典型误用：
mu.Lock()后遇到 error 提前 return，忘了mu.Unlock()；或 defer 写错位置，比如放在 if 分支里，分支没进就漏掉 - 嵌套锁顺序不一致才是真隐患：goroutine A 先
mu1.Lock()再mu2.Lock()，B 却反着来——只要并发稍高，就可能互相 hold 住。解决办法不是加超时，而是统一所有代码中对mu1、mu2的加锁顺序 - 持有锁期间别做任何可能阻塞的事：
ch 、<code>http.Get()、db.Query()……这些操作一旦卡住，锁就一直挂着，所有依赖这把锁的逻辑全被拖垮
用 pprof 和 GODEBUG=schedtrace=1000 看清 goroutine 真实状态
panic 日志只能告诉你“卡在哪”，但看不到“为什么卡”——比如一个 goroutine 显示停在 ，你得确认是没人发，还是发了但被 buffer 挡住，或是 receiver 已 exit。
立即学习“go语言免费学习笔记（深入）”；
- 加
import _ "net/http/pprof"并启动http.ListenAndServe("localhost:6060", nil)，访问http://localhost:6060/debug/pprof/goroutine?debug=2就能看到每个 goroutine 的完整调用栈，精准定位是卡在 send、recv 还是 Lock -
GODEBUG=schedtrace=1000 go run main.go每秒输出调度器快照，重点关注g数是否长期为 0（说明全阻塞）、gomaxprocs是否合理、有没有 goroutine 长期处于waiting状态却没人唤醒它 - 别只信
-race：它查数据竞争，不查死锁。但竞态常是死锁前兆——比如两个 goroutine 同时改同一个sync.WaitGroup计数，可能导致 wg.Wait() 永远等不到 Done
死锁排查最难的不是工具怎么用，而是意识到“等待”本身不是问题，问题在于谁该打破等待循环。channel 要有明确的关闭方，mutex 要有确定的释放点，goroutine 要有清晰的退出信号——所有这些，都不能靠“也许别人会做”来假设。
