sync.Cond 是 Go 中依赖互斥锁的条件等待原语，需用 for 循环二次检查条件，Signal 唤醒一个、Broadcast 唤醒所有等待者，典型用于生产者-消费者模型。
sync.Cond 是 Go 中用于协程间条件等待与唤醒的同步原语，它必须和互斥锁（*sync.Mutex 或 *sync.RWMutex）配合使用，不能独立工作。 它本身不保存状态，也不提供原子性判断逻辑，核心职责是：让一个或多个 goroutine 在某个条件不满足时挂起等待，待其他 goroutine 修改共享状态并确认条件可能已满足后，显式通知（Signal 或 Broadcast）唤醒等待者。正确使用的关键在于“检查条件 → 等待 → 唤醒后再次检查”的循环模式。
必须搭配互斥锁使用，且锁需在等待前持有
Cond 的 Wait 方法会自动释放传入的锁，并在被唤醒后重新获取该锁。因此调用 Wait 前，当前 goroutine 必须已持有该锁；否则 panic。这是最常见错误来源。
- 初始化 Cond 时，必须传入一个已初始化的 *sync.Mutex（或 *sync.RWMutex）指针
- 每次进入条件检查和 Wait 逻辑前，先 lock.Lock()；Wait 返回时锁已被重新持有，可安全读写共享变量
- 不要在 Wait 后直接假设条件成立——必须再次检查，因为可能存在虚假唤醒（spurious wakeup）或通知后条件又被其他 goroutine 改回
用 for 循环包裹 Wait，始终二次验证条件
Go 不保证 Wait 被唤醒时条件一定为真。所以标准写法是：for !condition { cond.Wait() }。这是强制约定，不是可选项。
- 错误示例：
if !ready { cond.Wait() }—— 可能跳过唤醒、错过条件、或误判状态 - 正确示例：共享变量
dataReady bool，消费者等待数据就绪：
cond.Wait()
}
// 此时 dataReady 为 true，可安全使用 data
Signal 和 Broadcast 的区别与选用场景
两者都用于通知等待者，但行为不同：
- Signal()：唤醒**一个**正在 Wait 的 goroutine（若存在）。适用于“一次通知、一人处理”的场景，如任务队列有新任务，只需唤醒一个 worker
- Broadcast()：唤醒**所有**正在 Wait 的 goroutine。适用于状态变更影响全体等待者，如资源池重置、全局开关关闭、缓存失效等
- 注意：Signal 不保证唤醒哪个 goroutine，也不保证立即执行；Broadcast 也不保证所有被唤醒者都能立刻获得锁，它们仍需竞争互斥锁
典型应用：生产者-消费者模型（带缓冲的单值信号）
以下是一个极简但完整的例子，模拟“一个生产者发一次数据，一个消费者等它”：
var (mu sync.Mutex
cond = sync.NewCond(&mu)
dataReady bool
data string
)
// 生产者
go func() {
mu.Lock()
data = "hello"
dataReady = true
cond.Signal() // 通知一个等待者
mu.Unlock()
}()
// 消费者
mu.Lock()
for !dataReady {
cond.Wait()
}
fmt.Println(data) // 输出 hello
mu.Unlock()
