sync.Cond本质是条件等待协调器，不保护数据也不替代互斥锁，需与同一把锁配合使用，Wait必须置于for循环中以防虚假唤醒或条件变更，Signal唤醒一个、Broadcast唤醒全部等待goroutine。
Cond 本质是啥：不是锁，是“喊一嗓子”的协调器
sync.Cond 不保护数据，也不替代 sync.Mutex 或 sync.RWMutex。它只是让一堆 goroutine 在某个条件成立时被唤醒——但“条件是否真成立”，得你自己用锁+判断来保证。常见错误是只调 c.Wait() 却没在循环里检查条件，结果错过信号或虚假唤醒。
- 必须搭配互斥锁使用：创建
sync.Cond时传入的<em>sync.Mutex</em>或sync.RWMutex，必须和保护共享变量的锁是同一个实例 -
Wait()会自动释放锁，并在被唤醒后重新获取锁——所以调用前必须已持有该锁 -
Signal()和Broadcast()不需要持锁，但通常应在修改完条件后、且仍持有锁时调用，避免竞态
比如等一个切片非空：
mu.Lock()
defer mu.Unlock()
for len(items) == 0 {
c.Wait() // 自动释放 mu，唤醒后重新 lock
}
// 此时 items 非空，且 mu 已 lock
Wait 必须放在 for 循环里：别信“只醒一次”
Go 的 Wait() 可能被系统虚假唤醒（spurious wakeup），也可能在 Signal() 后、goroutine 尚未真正调度前，条件又被其他协程改回不满足状态。直接用 if 判断会出错。
- 错误写法：
if len(data) == 0 { c.Wait() }→ 一醒就执行，不管条件还成不成立 - 正确写法：永远用
for len(data) == 0 { c.Wait() } - 条件判断语句必须和
Wait()在同一把锁保护下，否则读到的是脏数据
这不是风格问题，是并发安全的硬性要求。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Signal vs Broadcast：唤醒谁，得看场景
Signal() 最多唤醒一个等待的 goroutine；Broadcast() 唤醒全部。选哪个，取决于你的业务语义。
- 生产者-消费者模型中单个任务就绪：用
Signal()更高效，避免惊群 - 条件变更影响所有等待者（如“全局停止信号”“配置重载完成”）：必须用
Broadcast() - 注意：
Signal()不保证唤醒“最先等的那个”，调度顺序由 runtime 决定，不可依赖 - 如果用
Signal()但当前没 goroutine 在等，这个信号就丢了——不会排队，也不会累积
没有“唤醒指定 goroutine”的能力，Cond 不支持选择性通知。
Cond 的生命周期管理：别在锁外创建或销毁
sync.Cond 不是线程安全的可复制对象，它的 L 字段（指向锁）在创建后不能变。常见坑是：
- 在 goroutine 中临时 new 一个
sync.Cond并传入局部锁 → 锁作用域结束，Cond 就失效 - 复用
sync.Cond{L: &mu}字面量初始化（Go 1.22+ 允许），但若&mu是栈变量地址，可能逃逸失败或悬垂 - 用完不关心回收，但 Cond 本身无 Close 方法；只要底层锁还活着，Cond 就能用
稳妥做法：把 *sync.Cond 和它绑定的 *sync.Mutex 一起定义为结构体字段，生命周期对齐。
Cond 的难点不在 API，而在你得自己画清楚“谁改条件、谁等条件、谁发信号、锁在哪一层”。漏掉任意一环，就会卡死或跳过通知。
