Go中死锁指所有goroutine阻塞且无法唤醒，导致panic终止；常见于channel无人收发或Mutex误用，需明确通信边界、避免无缓冲channel单向依赖、合理控制goroutine生命周期。
Go 中的“死锁”通常不是传统意义上的线程死锁（如互斥锁嵌套等待），而是 goroutine 全部陷入阻塞且无法被唤醒，导致程序 panic 并终止。最常见的场景是 channel 操作无人接收/发送、或 sync.Mutex 使用不当引发的逻辑阻塞。解决核心在于：明确通信边界、避免无缓冲 channel 的单向依赖、合理控制 goroutine 生命周期。
排查死锁：看 panic 信息和 goroutine 栈
Go 运行时会在所有 goroutine 都阻塞时自动检测并 panic，输出类似：
fatal error: all goroutines are asleep - deadlock!此时可通过 runtime.Stack() 或在调试时用 go tool trace 查看 goroutine 状态。重点关注：
- 哪些 goroutine 停在
chan send或chan recv - 是否有 goroutine 持有 mutex 后进入 channel 等待，而接收方又在等该 mutex
- 主 goroutine 是否在
<-ch上永久等待，但没人 close 或 send
channel 死锁的典型场景与修复
无缓冲 channel 要求收发双方同时就绪，否则任一方都会阻塞。常见错误：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
同步发送后无接收者：比如在 main 中
ch <- 1，但没启动接收 goroutine 或接收逻辑未执行 - range 一个未关闭的 channel：for-range 会一直等待新值，直到 channel 关闭；若 sender 忘记 close，receiver 就永远卡住
- select 中 default 分支缺失 + 所有 channel 不可操作：若所有 case 都阻塞且无 default，当前 goroutine 死锁
修复建议：
- 发送前确保有活跃接收者，或改用带缓冲 channel（
ch := make(chan int, 1)） - sender 负责 close（通常在发送完所有数据后），receiver 用 for-range 安全消费
- select 中加入
default:避免阻塞，或用select { case 设超时
sync.Mutex 和 sync.RWMutex 的安全用法
Mutex 本身不会直接导致 Go runtime 报死锁，但可能引发逻辑死锁（如 A 等 B 的锁，B 等 A 的锁）。更常见的是：忘记 Unlock、在锁内调用可能阻塞的操作（如 channel send/recv）、或 defer unlock 失效。
- 始终配对使用 Lock/Unlock，优先用
defer mu.Unlock()，并在 Lock 后立即 defer - 避免在临界区内做 IO、网络调用、或向无缓冲 channel 发送 —— 这些可能阻塞，导致锁长期持有
- 多个 mutex 按固定顺序加锁（如按地址或名字排序），防止循环等待
- 读多写少场景用 RWMutex，注意
RUnlock不能在未RLock时调用，且写锁会阻塞所有读锁
设计习惯：让 goroutine 主动退出，而非被动等待
死锁常源于“等待不可达条件”。推荐用 context 控制生命周期：
- 用
ctx.Done()替代无条件 channel 接收：select { case v := - worker goroutine 在收到 cancel 后清理资源、关闭输出 channel，并 return
- 主 goroutine 用
sync.WaitGroup等待 worker 结束，而不是盲等某个 channel - 避免 “goroutine 泄漏”：启动了 goroutine 却没给它退出路径，最终因 channel 阻塞堆积
