Go 的 sync.Cond 避免丢通知，关键不是把 Signal 调得更早，而是让“共享条件的检查、状态修改和 Wait”都受同一个 Locker 保护。Signal 或 Broadcast 只负责唤醒等待者，真正决定能否继续的是条件本身。
固定写法是：持锁检查条件，条件不满足就调用 Wait，被唤醒后重新检查；生产者在同一把锁下修改条件，再选择唤醒一个或全部等待者。
参考文档：https://pkg.go.dev/sync#Cond
本文只讨论条件变量的等待与通知边界，不展开 channel 替代方案或完整调度器设计。
先分清通知与条件
sync.Cond 关联一个 Locker，通常是 *sync.Mutex。共享条件可以是“队列里有待处理任务”“服务已经关闭”或“缓冲区出现空间”。等待者不应该把一次通知当成永久事实，因为通知本身没有携带业务状态。
官方文档说明，Wait 会原子地解锁关联的 Locker 并挂起当前 goroutine，恢复后会重新加锁。因此，只要等待者在持锁期间检查条件，生产者就不能插入“修改条件但等待者还没进入 Wait”的空档。
把 Wait 放进条件循环
下面用待处理数量作为条件。pending 和 closed 都由 mu 保护；等待者只在“没有任务且尚未关闭”时休眠：
package main
import (
"fmt"
"sync"
)
type WorkQueue struct {
mu sync.Mutex
cond *sync.Cond
pending int
closed bool
}
func NewWorkQueue() *WorkQueue {
q := &WorkQueue{}
// Cond 与 mu 绑定，条件字段也必须由这把锁保护。
q.cond = sync.NewCond(&q.mu)
return q
}
func (q *WorkQueue) Take() (bool, int) {
q.mu.Lock()
defer q.mu.Unlock()
// 被唤醒后必须重新判断，不能假设任务一定还在。
for q.pending == 0 && !q.closed {
q.cond.Wait()
}
if q.pending == 0 {
// 关闭且没有剩余任务，调用方可以结束消费。
return false, 0
}
q.pending--
return true, q.pending
}
func (q *WorkQueue) Put() {
q.mu.Lock()
// 先修改条件，再通知等待者，二者处于同一保护域。
q.pending++
q.cond.Signal()
q.mu.Unlock()
}
func (q *WorkQueue) Close() {
q.mu.Lock()
// 关闭也是条件的一部分，需要唤醒所有可能正在等待的消费者。
q.closed = true
q.cond.Broadcast()
q.mu.Unlock()
}
func main() {
q := NewWorkQueue()
q.Put()
ok, left := q.Take()
fmt.Println(ok, left)
}
这里的 for 有两层作用：一是被唤醒后重新确认 pending 或 closed，二是多个消费者竞争同一份任务时，某个 goroutine 取走任务后，其他 goroutine 仍需回到条件判断。if 只能检查一次，容易把“收到通知”误写成“条件已经满足”。
在状态变化处发送通知
生产者的顺序应当保持简单：拿到同一把锁，修改条件，再发通知。Signal 只唤醒一个等待者，适合一次只增加一个任务；Broadcast 唤醒全部等待者，适合关闭状态或一次变化可能让多个等待者重新判断的场景。
func (q *WorkQueue) PutMany(n int) {
q.mu.Lock()
defer q.mu.Unlock()
if q.closed {
// 关闭后不再增加任务，避免条件含义前后不一致。
return
}
q.pending += n
// 多个任务可能满足多个消费者，所以统一唤醒后让各自重新判断。
q.cond.Broadcast()
}
通知可以在不持锁时调用，但把状态更新和通知放在同一保护域更容易审查，也能保证等待者看到的是一致的条件。需要注意的是，Signal 不会替你保存一张“通知票据”；如果当时没有等待者，后续进入的 goroutine 仍然必须依靠共享条件判断，而不是等待一条旧通知。
排查丢通知与退出边界
遇到 goroutine 长时间不醒，优先按下面的边界排查：
- 是否先解锁再等待：检查和
Wait之间如果没有同一把锁保护，生产者可能已经修改条件并发出通知，等待者随后却仍然进入休眠。 - 是否使用了
if：唤醒只代表需要重新检查，不能直接跳过条件判断。 - 是否更新了正确的条件：生产者增加的是
pending，等待者检查的也必须是同一个受保护字段。 - 是否有退出条件：关闭、取消或错误状态应成为条件的一部分，并通过
Broadcast让所有等待者有机会退出。
// 错误示意：检查与 Wait 之间重新解锁，可能错过状态更新通知。
q.mu.Lock()
if q.pending == 0 {
q.mu.Unlock()
// 生产者可能在这里 Put 并 Signal，通知不会替后续 Wait 排队。
q.mu.Lock()
q.cond.Wait()
}
q.mu.Unlock()
正确修复不是给 Wait 增加延时，而是恢复“持锁检查 + for 循环等待”的结构。这样即使通知发生在等待者真正挂起之前，等待者也会先看到已经改变的共享条件，不会因为一条没有排队的旧通知而永久等待。
常见追问
Wait 会无缘无故返回吗？ Go 文档说明它不会在没有 Signal 或 Broadcast 的情况下返回，但返回后条件仍应重新判断，因为其他等待者可能已经消耗了资源。
一个任务用 Signal 还是 Broadcast？ 通常一个新增任务配合 Signal 就够；关闭、批量更新或多个等待者都可能满足时，用 Broadcast，让每个 goroutine 自己检查条件。
