尘封十年的 Go 提案迎来转机？bradfitz 亲自操刀 Demo，让加锁也能 select 了
内容提要
Go issue #16620 提出已十年，探讨能否像 select channel 一样等待 sync.Cond。核心难点在于 channel 的电平触发与 Cond 的边沿触发语义冲突，Broadcast 尤其复杂。社区曾用桥接 goroutine、context.AfterFunc 等绕行。近日 bradfitz 提交 Demo CL，先推出 sync.Mutex.LockChan()，使加锁可响应取消或超时，但 Cond 与 Broadcast 问题仍未解决。
延伸解读
为什么从 Mutex 切入而非直接解决 Cond
Demo 选择先实现 Mutex.LockChan()，而不是直接啃 sync.Cond，背后有清晰的语义考量。加锁事件本质上是独占且只会发生一次的，天然适合用“关闭一次性 channel”来表达——关闭是幂等的，可被任意多次安全接收，从而绕开 Signal 场景下电平与边沿触发的矛盾。而 Cond.Broadcast 要唤醒的是任意多个、状态各异的等待者，语义复杂度完全不在一个量级，因此先收敛到 Mutex 是更易验证正确性的路径。
LockChan 的语义边界与循环重试问题
根据设计文档，mu.LockChan() 返回的 channel 会在成功获取锁时被关闭，且每次调用返回的 channel 应被视为一次性使用。这引出一个关键边界：若在 for { select { ... } } 循环中反复调用 LockChan()，每次是否都会产生全新且独立的 channel？这直接关系到该 API 在循环重试场景下是否安全好用，也是这份 Demo 希望验证清楚的核心语义点之一。
社区绕行方案的代价与风险
在官方方案缺位期间，社区尝试了多种绕行：额外起 goroutine 桥接 cond.Wait()，但外层因 ctx.Done() 提前退出时桥接 goroutine 往往回收不掉，造成泄漏；context.AfterFunc 配合 Cond.Broadcast 虽更简单，但必须用 Broadcast 而非 Signal，否则广播可能被其他等待者截胡；condchan 等第三方库则容易在 Signal 与 Broadcast 并发调用时出现竞态甚至 panic。这些实践从侧面印证了该问题语义上的微妙。
当前进展的定位：Demo 而非正式提案
需要明确的是，bradfitz 提交的 CL 828544 仍只是一份实验性 Demo，尚未进入正式的 proposal 评审流程，更谈不上进入某个 Go 版本。它只覆盖了 Mutex 场景，issue 标题里真正要解决的 sync.Cond（尤其是 Broadcast）问题目前仍无对应方案，RWMutex 是否需要及如何设计 RLockChan() 也仍是空白。因此它代表的是一个积极方向，而非已经落地的标准库能力。
Q&A
Go issue #16620 是什么？为什么它被搁置了十年？
Go issue #16620 是 2016 年由 bradfitz 提出的提案，希望让 sync.Cond 能像 channel 一样被 select，以便与 channel、context.Context 一起使用。搁置十年的根本原因是 channel 是电平触发，而条件变量的 Signal/Broadcast 是边沿触发，两者语义冲突，尤其 Broadcast 的转换极其复杂。
为什么 sync.Cond 不能直接放进 select 里？
因为 channel 是电平触发（值持续存在直到被读走），而条件变量的 Signal/Broadcast 是边沿触发（一次性事件，若无人等待则通知作废）。若强行将边沿触发转为电平触发的 channel，要么需手动排空信号，要么会产生远超预期的唤醒次数，Broadcast 尤其难以处理。
社区过去有哪些绕行方案来让条件变量可取消？
主要有三类：1) 额外起一个 goroutine 桥接 cond.Wait() 和 channel，但容易导致 goroutine 泄漏；2) 使用 context.AfterFunc + Cond.Broadcast，在 context 取消时主动广播，但必须用 Broadcast 而非 Signal，否则可能被其他等待者截胡；3) 第三方库如 condchan、missinggo 的 chancond，但容易在 Signal 与 Broadcast 并发时出现竞态甚至 panic。
bradfitz 提交的 Demo CL 828544 具体是什么？
该 Demo 没有直接实现 Cond.WaitChan()，而是给 sync.Mutex 增加了实验性的 LockChan() 方法。调用 mu.LockChan() 返回一个 channel，该 channel 在成功获取锁时被关闭，且每次调用返回的 channel 应一次性使用。它可以与 ctx.Done() 一起放入 select，实现带取消或超时的加锁。
Mutex.LockChan() 解决了什么问题？又留下了哪些未解决的问题？
它解决了“加锁”这一边沿事件转化为一次性关闭 channel 的问题，使抢锁能响应取消或超时，且关闭是幂等的，绕开了电平与边沿的矛盾。未解决的问题包括：仍只是实验性 Demo，未进入正式提案；只覆盖 Mutex，未解决 sync.Cond 尤其是 Broadcast 的语义；RWMutex 的 RLockChan() 设计也仍是空白。
为什么 Demo 选择从 Mutex 切入而不是直接解决 Cond？
因为 Mutex 的加锁事件本质上是“独占且只会发生一次”的，天然适合用“关闭一次性 channel”来表达，语义简单且容易验证正确性。而 Cond.Broadcast 需要唤醒任意多个状态各异的等待者，语义复杂度完全不在一个量级，因此先选择更小、更聚焦的切入点。
