Go语言中len(ch)不可信，因其返回值仅为竞态窗口内的瞬时采样，不反映同步状态，且channel设计为同步原语而非状态机，故不提供可靠缓冲区状态查询。
chan len() 返回值为什么不能信
Go 的 len(ch) 确实返回当前缓冲区中已排队元素个数，但它不是原子快照，而是一个「竞态窗口内的瞬时采样」。你拿到的数字可能在返回的下一毫秒就被其他 goroutine 的 send/receive 改变——更关键的是，它不反映任何同步状态：比如 len(ch) == 0 并不表示“此刻能非阻塞发送”，因为可能正有 goroutine 在 sendq 队列里等着发，但还没真正入队；len(ch) == cap(ch) 也不代表“马上就要死锁”，因为可能 recvq 里已有 goroutine 在等取。
为什么 runtime 不提供可靠的缓冲区状态查询
根本原因在于 channel 的设计哲学：它不是状态机，而是**同步原语**。Go 团队刻意避免暴露可被条件判断依赖的中间状态，因为这会诱导用户写出基于轮询（polling）的反模式代码。比如：
- 用
if len(ch) 替代 <code>select—— 这段代码在并发下必然出错：两个 goroutine 同时测到len ，然后都尝试 send，其中一个必阻塞或 panic（如果 channel 已关闭） - 用
for len(ch) > 0 { 清空 channel —— 如果此时无 goroutine 在 send，循环会卡死在第一次 <code>；如果 channel 未关闭，<code>range也一样会卡住
真正需要“探测是否可发送/接收”时该怎么办
没有银弹，但有明确路径：用 select + default 做瞬时尝试，或用额外信号协调。注意二者适用场景完全不同：
select { case ch 只告诉你「此刻能发」，不保证下次还能，也不防死锁。适合日志、指标等尽力而为场景- 若需可靠背压（如任务分发必须确保送达），应在 sender 侧维护计数器或用另一个
chan struct{}显式通知 receiver 准备就绪 - 想安全清空 channel？唯一办法是关闭它，再用
for range ch；否则必须配合外部锁或 context 控制生命周期
一个常被忽略的细节：len(ch) 对 closed channel 仍有效
channel 关闭后，len(ch) 仍返回剩余元素数，且 会继续成功直到读完。这点容易误判——你以为 <code>len(ch) == 0 就该退出，但实际上 channel 可能已关闭、缓冲为空，此时再 会立刻返回零值+<code>false，而不是阻塞。所以检查关闭状态必须靠接收时的第二个 bool 值，不能靠 len。
