sync.cond 不是 channel 替代品，须在 for 循环中调用 wait 以防虚假唤醒；signal/broadcast 必须在锁内调用；cond 必须绑定已初始化的 mutex/rwmutex；wait 返回时已持锁，需手动 unlock。
别用 sync.Cond 做一次性通知，也别裸写 cond.Wait() —— 它不是 channel 的替代品，而是为“多 goroutine 等同一动态条件”设计的协作原语。
Wait 必须在 for 循环里调用，不能用 if
虚假唤醒（spurious wakeup）是真实存在的：即使没人调用 Signal 或 Broadcast，Wait() 也可能返回。此时若只用 if 判断一次，goroutine 就会误以为条件已满足，接着访问空队列、读取未初始化数据，或触发 panic。
- 错误写法：
if len(queue) == 0 { cond.Wait() }→ 唤醒后不重检，风险极高 - 正确写法：
for len(queue) == 0 { cond.Wait() }→ 每次唤醒都重新校验 - 条件变量本身不保存状态，它只负责“挂起/唤醒”，真假全靠你用锁保护的变量来定义
Signal 和 Broadcast 必须在锁内调用才安全
虽然文档说 Signal 和 Broadcast 不强制要求持锁，但实际中必须放在 Lock() / Unlock() 之间。否则可能出现“通知丢失”：等待者刚进入 Wait() 的释放锁阶段，通知就发了，结果没人收到。
- 典型顺序：
cond.L.Lock(); updateSharedState(); cond.Signal(); cond.L.Unlock() - 不要把
Signal放在Unlock()之后 —— 中间可能有其他 goroutine 抢入并修改状态 -
Broadcast在上百 goroutine 等待时会引发惊群（thundering herd），唤醒全部再抢锁，多数又立刻Wait回去；高并发下优先考虑分批唤醒或换 channel +select
Cond 必须和 sync.Mutex 或 sync.RWMutex 绑定，不能单独 new
sync.Cond 本身不带锁，它的 L 字段必须指向一个已初始化的互斥锁实例。漏掉这步，Wait() 会 panic，或者导致竞态——因为条件变量的读写根本没被保护。
- 合法初始化：
mu := &sync.Mutex{}; cond := sync.NewCond(mu) - 非法操作：
cond := sync.NewCond(&sync.Mutex{})→ 锁是临时对象，地址可能失效 - 条件变量和锁是一对一绑定关系，多个
Cond共享同一个锁是允许的，但每个Cond必须有自己的L指向 - 别用
sync.RWMutex的RLock()配合Wait()——Wait()内部调用的是L.Unlock()，而RLock()对应的是RUnlock()，类型不匹配会 panic
最常被忽略的一点：每次 Wait() 返回时，你已经重新持有锁了，但很多人忘了在逻辑末尾 Unlock()，结果整个临界区被锁死。这不是 Cond 的 bug，是你没遵守“加锁 → 检查 → 等待 → 操作 → 解锁”的闭环。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
