go 运行时无主动死锁检测 api，死锁发生时会 panic 并输出“all goroutines are asleep - deadlock!”，此时应直接分析堆栈、pprof/block 快照和 -race 报告定位问题。
Go 运行时本身不提供“主动检测死锁”的 API，所谓“实现死锁检测”其实是利用其内置 panic 机制 + 工具链暴露阻塞状态，而不是写个函数就能返回 isDeadlocked。真正在代码里加检测逻辑，99% 是徒劳且误导的。
死锁 panic 就是检测结果，别绕开它
Go 程序一旦所有 goroutine 都卡在 channel、mutex、wg.Wait() 或 select {} 上，运行时会立即终止并输出：fatal error: all goroutines are asleep - deadlock!
这不是警告，是程序已不可恢复地停摆。此时堆栈信息就是唯一可信线索，必须直接看它，而不是试图“提前预测”。
- panic 日志第一行就告诉你问题性质，第二行开始列出每个 goroutine 的当前调用位置
- 重点关注
maingoroutine 停在哪——比如卡在ch ，说明发送无人接收；卡在 <code>，说明接收无人发送 - 其他 goroutine 若全停在同类操作（如全部
chan send），基本可断定收发配对缺失
pprof /debug/pprof/block 是最准的现场快照
死锁发生前，你可能只看到程序“变慢”或“没响应”，这时 /debug/pprof/block 能暴露真实阻塞点，比猜更可靠。
- 启动时导入
_ "net/http/pprof"并监听 HTTP 服务，访问http://localhost:8080/debug/pprof/block - 该页面显示所有因同步原语（channel、mutex、semaphore）而阻塞的调用链，含等待时长和 goroutine ID
- 若某
ch 操作等待超 5 秒，基本可确认接收端缺失或逻辑未启动 - 注意：该 endpoint 默认只在本地生效，生产环境需谨慎暴露
go run -race 不查死锁，但能防“伪死锁”
很多看似死锁的问题，实际是数据竞争导致逻辑错乱——比如一个 goroutine 没收到信号，只因共享变量被另一个 goroutine 错误覆盖。这时 -race 才是真正救命的开关。
- 运行
go run -race main.go，它会在竞态发生时立刻报错，指出哪两行代码并发读写同一变量 - 常见陷阱：for 循环中启动 goroutine 时捕获循环变量（
for _, v := range items { go func() { use(v) }() }），所有 goroutine 共享最后一个v - 闭包传参修复：改为
go func(v Item) { use(v) }(v)，或用局部变量vv := v; go func() { use(vv) }() - -race 不能替代死锁排查，但它能帮你排除“本该唤醒却没唤醒”的底层原因
带缓冲 channel 不等于免死锁，len(ch) == 0 也不代表可写
把 make(chan int) 改成 make(chan int, 10) 只是延迟死锁，不是消除死锁。而且 len(ch) 返回的是当前队列长度，不是“是否可写”的判断依据。
- 向已满缓冲 channel 发送仍会阻塞，
len(ch) == cap(ch)才表示满 - 无缓冲 channel 的
len(ch)永远是 0，不能用来判断是否有人在等接收 - 真正安全的写法是用
select+default做非阻塞尝试，或用select+time.After加超时 - 但
default分支高频轮询会浪费 CPU，超时时间设太短易误判，设太长又失去意义——它只是调试手段，不是生产解法
死锁没有“银弹式检测”，只有 panic 日志、pprof block 数据、-race 报告这三样东西拼起来才接近真相。最容易被忽略的是：别在 panic 后还去改逻辑猜原因，先完整复制那几行 goroutine 堆栈，再逐行对照代码里谁该收、谁该发、谁该关、谁该 unlock。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
