Go sync.Cond 接入 context 取消的等待封装方案

sync.Cond.Wait 本身没有 context.Context 参数，等待中的 goroutine 不会因为上下文取消自动醒来。实用的封装是：让取消回调获取与条件变量相同的 Locker，再调用 Broadcast；等待方醒来后重新检查共享条件和 ctx.Err()。这样既保留条件变量的谓词语义，也能让超时、请求断开或服务退出走到返回路径。

sync.Cond 取消等待的关键是把唤醒接回同一把锁

条件变量解决的是“状态没满足时先睡眠，状态改变后再重试”。它不保存业务结果，也不等价于一个可选择的 channel。官方文档要求调用方在持有 c.L 时观察或修改条件，并在循环中调用 Wait。因此取消要做的不是直接从另一个 goroutine 改写状态，而是把取消事件转换成一次受锁保护的唤醒。

下面的辅助函数把这个顺序固定下来：等待者持有锁；取消回调也获取同一把锁；回调只负责 Broadcast，真正的退出判断仍放在等待循环中。

package waitutil

import (
    "context"
    "sync"
)

// WaitContext 等待 ready 变为 true，或在 context 取消时返回原因。
func WaitContext(ctx context.Context, cond *sync.Cond, ready func() bool) error {
    // 已取消时直接返回，避免为一个不会开始的等待注册回调。
    if err := ctx.Err(); err != nil {
        return err
    }

    stop := context.AfterFunc(ctx, func() {
        // 回调拿同一把锁，保证取消与 Wait 的交接不丢唤醒。
        cond.L.Lock()
        cond.Broadcast()
        cond.L.Unlock()
    })
    defer stop() // 取消前正常结束时，阻止尚未启动的回调。

    cond.L.Lock()
    defer cond.L.Unlock()
    for !ready() {
        // Wait 返回只代表被唤醒，不代表条件已经满足。
        if err := ctx.Err(); err != nil {
            return err
        }
        cond.Wait()
    }
    return nil
}

WaitContext 的实现步骤与竞态边界

这里最容易写错的是回调直接调用 cond.Broadcast()。虽然文档允许调用方不持锁广播，但如果取消和等待的交接没有共享锁，代码就很难证明“检查取消”和“进入 Wait”之间不会留下空窗。回调先锁住 cond.L 后，若等待者还在检查，它会等到等待者释放锁；若等待者已经进入 Wait，回调则能在等待者注册后完成广播。

醒来后仍要回到 for 循环。普通条件通知可能只是别的状态变化，也可能有多个等待者竞争同一个资源；取消广播也只是告诉等待者“重新判断”，不是把条件改成了成功。

回调收尾、锁类型和 channel 替代条件

context.AfterFunc 返回的 stop 只表示“尽量阻止尚未启动的回调”。如果取消已经发生，回调可能正在等待 cond.L；stop 返回后也不代表回调已经结束。因此回调里不要触碰已经失效的业务对象，最好只做加锁、广播和解锁。

cond.L 可以是实现了 sync.Locker 的 Mutex，也可以是合适的 RWMutex 包装，但等待谓词涉及写入时通常用普通 Mutex 更容易审查。若需求只是“等一次事件”“广播后所有接收者都结束”或“同时监听取消和数据”，channel 通常更直观；只有需要多个状态谓词共享一把锁、并让等待者反复检查状态时，才值得保留 sync.Cond。

常见问题

为什么不在另一个 goroutine 里直接调用 Broadcast？

可以唤醒，但没有同一把锁就难以证明取消与 Wait 的交接顺序。把锁边界放进回调，能让取消只负责触发一次受控的重新检查。

Broadcast 后能直接返回 context.Canceled 吗？

不能。Broadcast 也可能来自正常状态变化，返回值必须以循环中的 ready() 和 ctx.Err() 为准。

所有超时等待都应该用 sync.Cond 吗？

不是。若状态可以表达为关闭 channel、数据 channel 或 select，优先使用 channel；Cond 更适合复杂共享谓词下的协作等待。