死锁因goroutine间相互等待导致，需检查channel收发是否配对、锁顺序是否一致；通过panic日志定位阻塞点，结合-race、pprof、trace等工具分析调用栈和同步操作，确保发送/接收、加锁/解锁成对且有唯一关闭方。

Go 程序出现 fatal error: all goroutines are asleep - deadlock，说明主 goroutine 和所有其他 goroutine 都在等待彼此释放资源，没有一个能继续执行。这不是竞态（race），而是明确的阻塞循环——必须有至少一个 goroutine 能发消息、收消息、解锁或退出，否则就死锁。

看 panic 日志定位卡点

Go 运行时在死锁时会打印所有 goroutine 的当前调用栈（默认开启）。重点看：

• main goroutine 停在哪一行（比如 或 mu.Lock()）
• 其他 goroutine 是否全卡在同类型操作上（如都在等同一个 channel 接收、都在等同一把 mutex）
• 有没有 goroutine 卡在 select {} 或空 for 循环里（无退出条件）

如果日志被截断，加 GODEBUG=schedtrace=1000 运行，每秒输出调度器快照，观察 goroutine 状态是否长期为 runnable 或 waiting。

检查 channel 使用是否匹配

最常见死锁来源：channel 发送/接收不配对，尤其无缓冲 channel。

• 向无缓冲 channel 发送前，必须有另一个 goroutine 同时准备接收；否则发送方永久阻塞
• 从 channel 接收前，必须有发送方或 channel 已关闭；否则接收方永久阻塞
• 忘记 close(channel) 导致 range 无限等待（如 for v := range ch { ... } 但没人关 ch）
• 多个 goroutine 共用一个 channel 但未协调关闭时机，比如一个 goroutine 关了，另一个还在发

技巧：用 select + default 避免盲等；用 len(ch) == cap(ch) 判断满，len(ch) == 0 判断空（仅限有缓冲）；对必须关闭的 channel，确保只有一个 goroutine 负责 close。

审查锁的获取顺序与范围

mutex、RWMutex、sync.Once 等同步原语用错也会导致逻辑死锁。

• 重复 Lock：同一个 goroutine 对同一 mutex 连续调用两次 Lock（没 Unlock）
• Lock/Unlock 不成对：defer Unlock 写错位置，或提前 return 漏掉 Unlock
• 嵌套锁顺序不一致：goroutine A 先锁 mu1 再锁 mu2，goroutine B 反过来先锁 mu2 再锁 mu1 → 潜在死锁
• 在持有锁时调用可能阻塞的函数（如写 channel、HTTP 请求、数据库查询）→ 锁持有时间过长，增加冲突概率

建议：用 -race 编译运行检测潜在竞争；给 mutex 加字段注释说明保护哪些变量；复杂场景改用 channel 通信代替共享内存加锁。

用工具辅助诊断

手动读代码易遗漏，善用 Go 自带和第三方工具：

• go run -race main.go：检测数据竞争（虽不直接报死锁，但常是死锁前置）
• go tool trace：生成 trace 文件，用浏览器打开，查看 goroutine 阻塞事件（Block、SyncBlock）、网络/系统调用等待
• pprof：访问 /debug/pprof/goroutine?debug=2 查看完整 goroutine 栈（需启用 pprof HTTP handler）
• IDE 插件（如 GoLand）可高亮未使用的 channel 操作、可疑的 defer Unlock

线上服务可加健康检查端点，定期 dump goroutine 栈到日志，发现堆积趋势及时干预。

基本上就这些。死锁不是玄学，它总发生在确定的同步点上。养成 channel 配对思维、锁最小化习惯、加上基础 trace 能力，90% 的死锁问题都能快速定位。不复杂但容易忽略。