cond.broadcast会唤醒所有当前正在wait的goroutine，但不唤醒尚未执行wait或已退出等待的goroutine；根本原因是未加锁调用wait、锁实例不匹配、未用for循环重检条件或条件本身未正确维护。
Cond.Broadcast 会唤醒所有正在 Wait 的 goroutine，但不会“捕获”还没调用 Wait 的协outine——它不是发消息，是拍醒此刻正在打盹的人。
为什么 Broadcast 后有些 goroutine 没响应？
常见现象是：调了 c.Broadcast()，但部分 goroutine 仍卡在 c.Wait() 不返回。根本原因不是广播失败，而是那些 goroutine 根本没“在等”：
- 刚启动、还在初始化，尚未执行到
c.Wait() - 已执行过一次
c.Wait()并被唤醒，但条件不满足又立刻重进Wait()—— 这种情况没问题，它仍在等待队列里 - Wait 前没加锁，导致
c.Wait()直接 panic，goroutine 提前退出（错误信息：sync: Cond.Wait outside of lock） - 用了不同的锁实例（比如多个
sync.Mutex{}），或混用了sync.RWMutex（Cond只接受*sync.Mutex或自定义sync.Locker）
Wait 必须用 for 循环包裹，不能只用 if
即使只发一次 Broadcast，也不能假设唤醒后条件就成立。Go 运行时允许虚假唤醒（spurious wakeup），且多个 goroutine 可能同时被唤醒、竞争同一资源。所以必须在锁保护下重新检查条件：
for !dataReady {<br> c.Wait()<br>}
而不是：
if !dataReady {<br> c.Wait()<br>}
否则可能读到空切片、访问 nil 指针，直接 panic。
Broadcast 和 Signal 怎么选？看语义，不是看性能
别因为 “Broadcast 开销大” 就硬用 Signal 替代，这容易漏通知：
-
c.Signal()：适合“单任务分发”，比如工作池里唤醒一个空闲 worker 取走一个任务 -
c.Broadcast()：适合“状态全局变更”，比如配置重载完成、服务进入关闭流程、缓冲区从空变非空（生产者写入后通知所有消费者） - 用
Signal代替Broadcast时，如果多个 goroutine 都在等同一个条件，很可能只有第一个被唤醒，其余永远阻塞
最容易被忽略的三件事
一是 c.Wait() 前必须已持有 c.L 锁，否则 panic；二是 Wait() 返回后锁已被自动重新获取，别在 defer Unlock() 里乱放；三是条件变量本身不存状态——dataReady 这种标志位必须由你用 mu.Lock() 保护读写，Cond 只负责“喊一嗓子”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
