go中典型死锁是channel操作未配对：向无缓冲channel发送时无人接收，或接收时无人发送，运行时panic提示“all goroutines are asleep – deadlock!”。
channel 操作未配对导致的死锁
Go 中最典型的死锁，就是 goroutine 在向无缓冲 channel 发送数据时阻塞，且没有其他 goroutine 从该 channel 接收；或从 channel 接收时阻塞，但无人发送。编译器无法静态检测这类逻辑死锁，运行时 panic 提示为 fatal Error: all goroutines are asleep - deadlock!。
常见诱因：
- 在主 goroutine 中直接
ch ，而接收逻辑被错误地放在另一个未启动的 goroutine 里 - 用
select读 channel 时漏写default，且 channel 暂时空 - 关闭 channel 后仍尝试发送（会 panic），但更隐蔽的是：关闭后继续接收——这本身不 panic，但若接收方没感知关闭，可能卡在循环中等不到新数据
func main() { ch := make(chan int) ch <- 42>sync.Mutex 或 sync.RWMutex 重复加锁
sync.Mutex 不可重入。同一个 goroutine 连续两次调用 mu.Lock() 会导致永久阻塞——它不会报错，也不会超时，只会卡死。
容易踩坑的场景：
立即学习“go语言免费学习笔记（深入）”；
- 方法内部调用自身（递归）且都持锁
- 组合结构体嵌套调用不同方法，各自独立加锁，但实际共享同一把锁
- defer mu.Unlock() 写在函数开头而非临界区结尾，导致解锁时机错误
func (s *Service) DoWork() { s.mu.Lock() defer s.mu.Unlock() // 错：这里 defer 的是第一次 Lock 对应的 Unlock s.mu.Lock() // 死锁：第二次 Lock 永远等不到释放 // ... }WaitGroup 使用不当引发的等待僵局
sync.WaitGroup 本身不直接导致死锁，但误用会让主 goroutine 永远等待不存在的完成信号。
典型错误：
-
wg.Add(1)在 goroutine 启动之后才调用（竞态，Add 可能被跳过） - goroutine 中忘记调用
wg.Done()，或因 panic 未执行到（应配合 defer） - 在循环中反复创建新 WaitGroup 实例，却对旧实例调用
Wait()
func main() { var wg sync.WaitGroup for i := 0; i < 3; i++ { go func() { // wg.Add(1) 漏了！下面 wg.Wait() 将立即返回，或更糟：如果 wg 已 Add 过但没 Done，就永远等 time.Sleep(time.Second) // wg.Done() 也漏了 }() } wg.Wait() // 可能立刻返回（wg 计数为 0），也可能死锁（若某处误 Add 但没 Done） }select + timer 组合中的隐式阻塞
看似安全的 select 如果只包含带 time.After 的 case，且没有 default 或其它可就绪 channel，仍可能因 timer 未触发而长期挂起——这不是死锁（runtime 能识别），但行为等效于“逻辑卡住”。
真正危险的是：timer 和 channel 共存时，误认为 “只要 timer 到了就一定走 default”，其实 select 是随机选择多个就绪 case 的，若 channel 恰好在此刻就绪，timer 就被跳过了。
- 依赖
time.After做超时，但未用case +case 配对，而是单独启动 goroutine 写 channel，主逻辑只等 timer——这不算死锁，但业务会丢数据 - 在循环中反复创建新 timer，却不 stop，造成 goroutine 泄漏+资源耗尽，间接诱发调度延迟甚至疑似死锁
select { case msg := <-datach: handle(msg) case <-time.after(5 * time.second): log.println("timeout")>
死锁往往不是单点错误，而是多个同步原语在时序和所有权上的错配。调试时别只盯 panic 信息，先确认所有 channel 是否有确定的发送/接收端、所有锁是否成对出现、所有 WaitGroup 的 Add/Done 是否严格对应——尤其注意那些“本该执行却没执行”的 defer 或 done。