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 + <code><-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 发），长期驻留内存，最终拖垮系统。这类问题往往在压测或上线后才暴露。
立即学习“go语言免费学习笔记（深入）”；
- 避免在 goroutine 内部无条件等待：
for { select { case 若 <code>ch已关闭且无其他 case，会陷入空转 - 给超时控制加
time.After或context.WithTimeout：select { case - 用
runtime.NumGoroutine()在测试中做粗略监控，突增说明可能有泄漏 - pprof 是关键工具：
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2可看所有活跃 goroutine 的堆栈
WaitGroup 使用不当导致的等待悬空
sync.WaitGroup 本身不会死锁，但误用会让 main goroutine 永远卡在 wg.Wait()，表现为“程序不退出”。常见原因是 Add() 和 Done() 不匹配，或在 goroutine 启动前未正确调用 Add()。
-
wg.Add(1)必须在go func()之前调用，否则可能Done()先于Add()执行，触发 panic - 不要在循环中重复
wg.Add(1)却只调一次Done()；也不要反过来 - 如果 goroutine 可能提前返回，确保每个出口都调用
wg.Done()，或用defer wg.Done() - 注意
WaitGroup不能被复制，必须传指针；局部变量初始化后立即传参，别用字面量临时构造
实际项目里最棘手的往往是 channel 和 WaitGroup 混用时的状态耦合 —— 比如某个 goroutine 既要往 channel 发结果，又要调 wg.Done()，但发操作阻塞了，Done() 就永远不执行。这种地方得靠清晰的控制流拆分和 context 控制来兜底。
