<p>fatal error: all goroutines are asleep - deadlock! 是Go运行时触发的立即终止错误，由checkdead()函数在所有goroutine均处于park状态且无可唤醒路径时直接panic，不执行defer，无恢复可能。</p>
Go语言死锁不是“可能出问题”，而是运行时一旦触发就立即 panic 并终止程序——fatal error: all goroutines are asleep - deadlock! 这句话就是最终判决书，没有重试、没有恢复，只有退出。它不靠日志埋点或监控告警发现，而是在所有 goroutine 都卡住的瞬间由 runtime 自动判定并崩溃。
为什么 fatal error: all goroutines are asleep - deadlock! 一出现就必须立刻处理
这不是性能问题，也不是超时可容忍的延迟；这是程序逻辑断裂的明确信号。runtime 的 checkdead() 函数在每轮调度末尾扫描：如果当前所有 goroutine 全部处于 park 状态（等 channel、等 mutex、等 timer、等 wg.Wait），且无任何可唤醒路径，就直接 fatal。这意味着你看到这条错误时，程序已完全失去活性，连 defer 都不会执行。
- 它不区分是通道未关闭、锁顺序错乱，还是 WaitGroup 忘记 Done —— 只要结果是“全卡住”，就 panic
- panic 日志里列出的 goroutine 堆栈是唯一线索，必须逐行看谁停在
mu.Lock()、或 <code>wg.Wait() - 本地复现率高，但 CI/线上容易被并发节奏掩盖；加
GODEBUG=schedtrace=1000可强制每秒输出调度快照，确认是否长期G=0
无缓冲 channel 先发后收必死锁，for range ch 不 close 就永远等
这是新手最常栽跟头的地方。无缓冲 channel 的发送操作会阻塞，直到有 goroutine 在另一端接收；反之亦然。单 goroutine 内写 ch 是经典死锁，因为没有第二个 goroutine 来配对。
-
for v := range ch底层等价于持续调用<-ch，直到 channel 被close(ch)—— 如果没人 close，它就永远等下一个值 - 树遍历类场景中，常见错误是启动 goroutine 发送完所有节点值后直接返回，忘了 close(ch)，导致主 goroutine 卡在 for range
- 用
select { case v := <-ch: ... default: ... }不能解决根本问题：default 是轮询空转，不是释放阻塞；它只是掩盖死锁，让 CPU 白跑 - 正确做法是用
sync.WaitGroup计数发送完成，然后 close：wg.Done() 后 close(ch)，确保接收方能退出
多个 sync.Mutex 锁顺序不一致，循环等待直接触发死锁
两个 goroutine 分别持有 A 锁请求 B、持有 B 锁请求 A，就会形成 Coffman 条件里的“循环等待”。Go 运行时不检查锁依赖图，只看最终状态，所以只要结果是双方都卡在 muA.Lock() 或 muB.Lock()，就 fatal。
立即学习“go语言免费学习笔记（深入）”；
- 不要靠“概率低”侥幸：即使 99% 时间不触发，压测或特定时序下仍会 panic
- 统一排序是最可靠解法：比如按锁变量的内存地址排序，
if &muA < &muB { muA.Lock(); muB.Lock() }，避免 AB/BA 交错 -
sync.RWMutex更危险：同一个 goroutine 多次RLock()或先RLock()后Lock()会破坏内部计数，表现为卡在(*RWMutex).RLock，pprof 显示大量 gopark - 开发期可用
go-deadlock替换原生sync包，它会在尝试获取锁超时时 panic 并打印调用链，提前暴露隐患
数据库事务死锁和 Go 运行时死锁是两回事，fatal error 往往是假象
MySQL 返回 Deadlock found when trying to get lock 或 PostgreSQL 报 ERROR: deadlock detected，Go 层面不会 panic，只会返回 *sql.ErrNoRows 类错误。但若应用没捕获重试，事务卡住、HTTP 请求超时、goroutine 积压，最终可能导致所有活跃 goroutine 都在等 DB 响应——这时 runtime 才会报 all goroutines are asleep，但它不是根源。
- 数据库死锁错误码必须显式判断：MySQL 用
strings.Contains(err.Error(), "Deadlock")，PostgreSQL 用pgerr.Code == "40P01" - 重试必须幂等：不能在重试时重复扣款、发消息；建议用 context 控制总超时，并用指数退避（10ms → 30ms → 100ms）
- 预防比处理更重要：事务内更新多行时，始终按主键升序锁定（
ORDER BY id），破坏循环等待条件 - ORM 如 GORM 不会自动重试，
db.Transaction()只是封装，重试逻辑必须手写在 service 层
真正难的不是写出不死锁的代码，而是在多人协作、模块分层、ORM 封装、中间件注入之后，还能清晰追踪每一把锁、每一个 channel 的生命周期。runtime 的死锁检测像一面镜子，照出来的不是某一行 bug，而是整个并发设计的脆弱性。
