死锁检测触发条件是所有 goroutine 均处于非可运行状态；Go 运行时在程序即将进入“全局静默”时 panic，报 fatal error: all goroutines are asleep - deadlock，依据是当前所有 goroutine 的实际调度状态。
死锁检测触发条件：所有 goroutine 都处于非可运行状态
Go 运行时会在程序即将进入“全局静默”时主动 panic，报出 fatal error: all goroutines are asleep - deadlock。这个判断不是靠预测，而是基于当前所有 goroutine 的实际调度状态——只要每个 goroutine 都卡在某个阻塞点（如 、ch 、sync.Mutex.Lock()、time.Sleep() 或系统调用），且没有 goroutine 处于 runnable 或 running 状态，运行时就认为“无唤醒可能”，立即终止程序。
未缓冲 channel 是最常见死锁诱因
未缓冲 channel 的发送/接收必须严格同步：一个 goroutine 执行 ch ，另一个必须**同时**执行 ，否则双方都会永久阻塞。单 goroutine 中顺序写 ch 紧跟 必然死锁，因为第二条语句根本没机会执行。
- 错误写法：
c := make(chan int); c → 第二行永远不会到达 - 正确写法之一：
c := make(chan int); go func() { c → 发送与接收分属不同 goroutine - 正确写法之二：
c := make(chan int, 1); c → 缓冲区容纳一次发送，不阻塞
cgo 场景下死锁检测可能失效
当代码引入 cgo（比如用了 net/http、os/exec 或任何调用 C 库的包），Go 运行时无法准确判断 goroutine 是否“真死了”。因为 C 代码可能在后台通过 pthread 唤醒 Go 函数（例如网络就绪回调 runtime.netpoll），运行时只能保守假设“还有唤醒可能”，从而跳过死锁 panic。
- 表现：看似必死锁的代码（如主线程发完数据后等接收）却静默挂起，不报错
- 验证方式：设环境变量
CGO_ENABLED=0重新编译运行，若此时 panic 出现，基本可确认是 cgo 干扰了检测 - 注意：这不是 bug，是设计权衡——宁可漏报，也不误杀真实异步 IO 场景
检测本身不防死锁，只做终局裁决
运行时死锁检测是最后一道防线，它不分析代码逻辑，也不插桩监控 channel 使用模式。它只看此刻所有 goroutine 的实时状态快照。这意味着：
- 静态工具（如
go vet）能发现部分明显问题（如同一 goroutine 中连续 send/receive），但覆盖有限 - pprof 的
goroutineprofile 可帮你看到谁卡在哪条 channel 操作上，但需手动关联上下文 - 真正可靠的防御，是设计时就避免“单点依赖”：每个
都要有明确的发送方（或close(ch)），尤其注意 goroutine 退出后是否还留有未消费的数据
最容易被忽略的是：channel 关闭后继续接收不会死锁，但往已关闭的 channel 发送会 panic；而未关闭的 channel 上，接收方永远不知道“对方是否还会发”，这种不确定性才是死锁温床。
