sync.cond必须与互斥锁配合使用，其本身不保存状态；wait前须持锁，唤醒后需循环检查条件，避免虚假唤醒；signal/broadcast建议在锁内调用；简单通知优先用channel。
Cond 必须和互斥锁一起用，单独 new(sync.Cond) 没有意义
sync.Cond 本身不保存状态，它只是对底层 Locker 的“条件通知”增强。你不能靠 Cond.Wait() 等待某个变量变 true 就完事——必须先用互斥锁保护该变量的读写，否则会竞态。
常见错误是这样写：
var ready bool
cond := sync.NewCond(&sync.Mutex{})
// …… goroutine 中直接 cond.Wait() —— 错！ready 没被锁保护，读写都可能乱
- 正确做法：用
sync.Mutex或sync.RWMutex包裹条件判断和等待逻辑 - Wait 前必须已持有锁；Wait 返回时自动重新持有锁（所以退出前要记得
Unlock()） - Signal/Broadcast 不要求持有锁，但实践中建议在锁内调用，避免通知丢失
Wait 会自动释放锁并挂起，但唤醒后需重新检查条件
Cond.Wait() 不是“等条件成立”，而是“等别人 Signal/Broadcast + 自己重新抢到锁 + 你自己再判断一次”。这是最常被忽略的点——漏掉二次检查，就会出现虚假唤醒或逻辑跳过。
典型场景：生产者往缓冲队列塞数据，消费者等 len(queue) > 0 才取。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
if len(queue) == 0 { cond.Wait() }→ 唤醒后不检查，可能 queue 又空了 - 正确写法：必须用
for len(queue) == 0 { cond.Wait() }循环等待 - Signal 是唤醒一个等待者，Broadcast 唤醒全部；高并发下 Broadcast 更安全，但代价略高
别用 Cond 实现简单的一次性通知，用 Channel 更自然
如果只是“等一个事件发生”，比如初始化完成、某个任务结束，sync.Cond 是过度设计。Go 的 channel 天然支持阻塞等待、类型安全、可关闭语义，且更易读。
对比：
- Cond 版本：需要额外维护
ready bool、互斥锁、Cond 实例，Wait 要循环，Signal 要确保时机 - Channel 版本：
done := make(chan struct{})，发端close(done)，收端即可，无竞态风险 - Cond 适合多 goroutine 等待同一动态条件（如资源池有空位、队列非空），且该条件由多个写操作共同影响
Cond.Broadcast 在高并发下可能触发惊群，注意性能边界
当上百个 goroutine 同时 Wait()，一次 Broadcast() 会让它们全部被唤醒、抢锁、检查条件、多数又立刻 Wait 回去——这就是“惊群效应”。虽然 Go runtime 做了一定优化，但压测时仍可观测到锁争用飙升。
- 能用
Signal()就别用Broadcast()，尤其当你知道只需唤醒一个消费者时 - 若必须 Broadcast，考虑加一层轻量级状态分片，比如把等待者按 key 分组，只唤醒相关组
- 注意：Cond 没有超时机制，Wait 不支持 context；需要超时请自己封装或换 channel + select
Cond 的难点不在 API，而在对“条件状态”的建模是否严密——锁的范围、检查的时机、唤醒的粒度，三者错一个，就容易卡死或跳过逻辑。写完务必用 -race 跑一遍。
