Go 运行时在所有 goroutine 都阻塞且无法唤醒时触发 fatal error: all goroutines are asleep - deadlock!，不可恢复；常见原因是无缓冲 channel 发送后无人接收，如 main 协程直接写入未读 channel。
go 运行时会在所有 goroutine 都阻塞且无法唤醒时 panic 报 fatal error: all goroutines are asleep - deadlock!，这不是可恢复错误，而是程序已彻底卡死。它不难复现，但排查成本高——尤其当死锁只在特定数据流或压力下触发时。
无缓冲 channel 发送没人接收就立刻死锁
这是新手最常踩的坑：在 main 协程里直接向无缓冲 channel 写数据，又没起另一个 goroutine 去读。
- 错误写法：
ch := make(chan int); ch —— 语句卡住，后续代码永不执行，运行时立刻 panic - 正确做法：要么用带缓冲 channel（
make(chan int, 1)），要么确保发送和接收在不同 goroutine 中配对 - 注意：哪怕只差一行
go func() { fmt.Println(，顺序错位也会导致死锁（比如先 <code>ch 再起 goroutine）
range 通道前忘了 close 就等同于无限等待
for v := range ch 的语义是“一直收，直到 ch 被关闭”。如果发送方 goroutine 已退出，但没调 close(ch)，主 goroutine 就永远停在这儿。
- 典型场景：树遍历、分片求和、多路结果聚合 —— 所有发送逻辑结束，但没人负责关 channel
- 安全模式：用匿名 goroutine 封装发送 +
close()，例如go func() { Walk(t, ch); close(ch) }() - 别依赖 defer close(ch)：如果函数提前 return，defer 不会执行；也别在多个 goroutine 里 close 同一个 channel，会 panic
select 没写 default 或 timeout 就等于主动找死锁
select 本身不提供超时，它只是“等任意一个 case 就绪”。如果所有 channel 都阻塞，又没 default 分支，就会永久挂起。
- 常见误用：在 for 循环里反复
select { case ，但 <code>done可能永远不会被 close - 修复方式：加
default（非阻塞轮询）或case （带超时） - 更健壮的做法是结合
context.Context：用ctx.Done()替代裸 channel，天然支持取消和超时
sync.Mutex 多把锁顺序不一致必然 AB-BA 死锁
两个 goroutine 分别按不同顺序获取两把锁，是经典的循环等待。Go 运行时无法检测这种局部死锁，程序会静默卡住（CPU 归零，goroutine 数稳定但不下降）。
- 例子：goroutine A 先 lock
mu1再 try lockmu2；goroutine B 反过来，先mu2后mu1 - 解法不是加更多锁，而是约定顺序：比如始终按变量地址升序加锁（
if &mu1 ），或用单个锁保护多个资源 - 警惕嵌套调用：函数 A 拿了
mu1后调函数 B，B 又去拿mu2—— 表面看没冲突，实际可能和别的 goroutine 构成循环
真正难防的不是 panic 式死锁，而是那些不报错、不占 CPU、goroutine 数缓慢上涨的“隐性死锁”：某个 goroutine 在 channel 上永久等待，但它的发送/接收逻辑被条件分支跳过了，或者 context 已 cancel 却没检查 ctx.Err()。这类问题必须靠 runtime.NumGoroutine() 监控 + go tool trace 抓阻塞点，光看代码很难发现。
