cond不能单独使用，必须配合mutex，因为wait前须持有关联的mutex，否则会panic；且wait必须置于for循环中防虚假唤醒，signal唤醒一个、broadcast唤醒全部等待者，但均需竞争锁才能继续执行。
Cond 为什么不能单独用，必须配 mutex
Go 的 sync.Cond 不是锁，它不保证临界区安全——这是新手最常踩的坑。你调用 c.Wait() 前，必须已持有与之关联的 *sync.Mutex（或 *sync.RWMutex），且 Wait() 内部会自动释放该锁，并在被唤醒后重新获取。如果没加锁就调 Wait()，程序会 panic：sync: Cond.Wait while not holding associated mutex。
常见错误写法：
c := sync.NewCond(&sync.Mutex{})
go func() {
c.Wait() // panic！没 lock 就 Wait
}()
正确姿势：
- 先
mu.Lock() - 检查条件是否满足（通常用 for 循环，防虚假唤醒）
- 不满足则
c.Wait()（此时会自动 unlock，唤醒后自动 re-lock） - 条件满足后处理逻辑，最后
mu.Unlock()
为什么 Wait 必须放在 for 循环里
条件变量存在虚假唤醒（spurious wakeup）：即使没人调 Signal() 或 Broadcast()，Wait() 也可能返回。Go 不保证唤醒一定由通知触发，所以不能用 if 判断条件，必须用 for 循环重检。
典型结构：
mu.Lock()
for !conditionMet() {
c.Wait()
}
// 此时 conditionMet() 为 true，且 mu 仍被持有
doWork()
mu.Unlock()
漏掉循环的后果：线程醒来后直接执行后续逻辑，但条件其实未达成，导致数据错乱或 panic。
注意：conditionMet() 必须是能被其他 goroutine 修改的共享状态，且读取时需在锁保护下进行（否则有竞态）。
Signal 和 Broadcast 的实际行为差异
c.Signal() 唤醒**一个**正在等待的 goroutine（如果有），c.Broadcast() 唤醒**所有**等待者。但关键点在于：唤醒不等于立即执行——被唤醒的 goroutine 仍需竞争 mutex，只有抢到锁的才能继续往下走。
适用场景建议：
- 用
Signal()：当只有一个 goroutine 能消费当前状态变更时（如生产者-消费者中单个 item 就绪） - 用
Broadcast()：当状态变更可能影响多个等待者，或不确定谁该响应时（如关闭信号、资源重置）
性能提示：Broadcast 在大量 goroutine 等待时开销明显，可能引发惊群效应；Signal 更轻量，但若唤醒错对象（比如唤醒了不关心该事件的 waiter），会导致“饥饿”——得靠业务逻辑确保唤醒目标正确。
Cond 与 channel 在协作场景中的取舍
多数简单同步场景（如“等某个值变为 true”“等队列非空”），优先用 channel：语义清晰、自带阻塞、无需手动管理锁。例如：
// 等待 ready 标志 <p>Cond 的不可替代场景集中在：需要**多个 goroutine 等待同一条件，且条件判断复杂或开销大**（比如轮询数据库连接池是否空闲），或者需支持**广播唤醒+细粒度锁控制**（如读写锁配合条件等待）。</p> <p>容易忽略的一点：<code>sync.Cond</code> 的 <code>L</code> 字段是导出的，但**绝不应被外部修改**——一旦替换底层锁，原有等待者的行为将不可预测。初始化后就别碰它。</p>
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
