在 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 <- 1; }()
go func() { fmt.Println("len =", len(ch)) }() // 安全：不会 panic，无竞态⚠️ 但关键限制在于：len(ch) 返回的是调用瞬间的快照值，不具备一致性保证。
- 若其他 goroutine 正在执行
ch 或 <code>，该长度可能在返回后立即改变； - 因此，绝不可将
len(ch) == 0作为“通道为空、可安全关闭”的依据，也不能用len(ch) > 0来“乐观地”尝试非阻塞接收（select+default才是正确方式）。
✅ 正确实践示例：
// ❌ 错误：竞态敏感、逻辑不可靠
if len(ch) > 0 {
val := <-ch // 可能阻塞，因 len() 后已被消费
}
// ✅ 正确：使用 select 实现非阻塞/超时安全操作
select {
case val := <-ch:
fmt.Println("received:", val)
default:
fmt.Println("channel empty now")
}? 总结：
-
len(channel)是线程安全的（goroutine-safe），可放心调用； - 但它不是同步原语——不提供内存可见性保障，也不构成 happens-before 关系；
- 若需基于通道状态做协调（如等待非空、判断是否可关闭），应使用
select、sync.WaitGroup、context或显式信号 channel，而非依赖len()的瞬时值。
