在 Go 中，len(channel) 调用本身是并发安全的，不会引发 panic 或数据竞争，但其返回值在多 goroutine 环境下瞬时失效，不可用于同步决策。
在 go 中，`len(channel)` 调用本身是并发安全的，不会引发 panic 或数据竞争，但其返回值在多 goroutine 环境下瞬时失效，不可用于同步决策。
Go 的 len() 内置函数对 channel 的调用是原子且无副作用的：它仅读取 channel 内部缓冲队列的当前长度（即已发送但尚未接收的元素数量），不修改 channel 状态，也不阻塞。因此，从内存安全和 runtime 稳定性角度看，多次或并发调用 len(ch) 不会触发 data race，也无需额外加锁。
ch := make(chan int, 5)
go func() { ch <p>⚠️ 但关键限制在于：<strong><code>len(ch)</code> 返回的是调用瞬间的快照值，不具备一致性保证</strong>。 </p>
- 若其他 goroutine 正在执行
ch 或 <code>，该长度可能在返回后立即改变； - 因此，绝不可将
len(ch) == 0作为“通道为空、可安全关闭”的依据，也不能用len(ch) > 0来“乐观地”尝试非阻塞接收（select+default才是正确方式）。
✅ 正确实践示例：
// ❌ 错误：竞态敏感、逻辑不可靠
if len(ch) > 0 {
val := <p>? 总结： </p>
-
len(channel)是线程安全的（goroutine-safe），可放心调用； - 但它不是同步原语——不提供内存可见性保障，也不构成 happens-before 关系；
- 若需基于通道状态做协调（如等待非空、判断是否可关闭），应使用
select、sync.WaitGroup、context或显式信号 channel，而非依赖len()的瞬时值。
