channel操作不匹配导致死锁：向无缓冲channel发送数据时若无goroutine同时接收，程序将永久阻塞；常见于main中发送后直接退出、for range遍历未关闭channel、多goroutine互相等待收发。
channel 操作不匹配导致的死锁
Go 中最常见的死锁来源是 channel 的发送与接收没有成对发生。比如向一个无缓冲 channel 发送数据，但没有 goroutine 在同一时刻准备接收，程序就会永久阻塞在 send 上。
典型错误场景包括：在 main goroutine 中向无缓冲 channel 发送后直接退出；或用 for range 遍历一个未被关闭的 channel；又或者多个 goroutine 互相等待对方先收/先发。
- 无缓冲 channel 必须配对使用：
go func() { ch +，不能只做单边操作 - 带缓冲 channel 虽可暂存数据，但若容量为 0（即等价于无缓冲），行为相同
- 用
select加default分支避免无限等待：select { case ch - 务必确保 channel 关闭前所有发送已完成，且接收方能感知结束（如配合
close(ch)和for range ch）
sync.Mutex 或 sync.RWMutex 的误用
死锁不一定只发生在 channel 场景。当同一个 goroutine 多次调用 mu.Lock()（未解锁就重入），或在持有读锁时尝试获取写锁（mu.RLock() 后跟 mu.Lock()），都会触发死锁 —— Go 运行时会检测到并 panic 报出 fatal error: all goroutines are asleep - deadlock!。
- 不要在已持有
mu.Lock()的函数中，再调用另一个可能也持相同锁的函数，除非明确设计为可重入（标准库sync.Mutex不支持） -
sync.RWMutex允许多读，但一旦有 goroutine 调用Lock()，后续所有RLock()都会被阻塞，直到写锁释放 - 用 defer 确保解锁：
mu.Lock(); defer mu.Unlock()，但注意 defer 在函数 return 前才执行，若中间 panic 且没 recover，仍可能漏解锁 - 考虑用
sync.Once替代手写双重检查锁逻辑，减少出错概率
goroutine 泄漏引发的隐性死锁
严格来说这不是死锁（程序仍在运行），但效果类似：goroutine 持有资源、等待永远不会发生的事件（如从已关闭的 channel 读、或向无人接收的 channel 发），长期驻留内存，最终拖垮系统。这类问题往往在压测或上线后才暴露。
