len(channel) 在 Go 中是并发安全的，可被任意 goroutine 安全调用；但其返回值仅反映调用瞬间的瞬时长度，若存在其他 goroutine 同时收发数据，则该值可能立即失效，不可用于条件判断或同步逻辑。
go 中 `len(channel)` 是并发安全的，可被任意 goroutine 安全调用；但其返回值仅反映调用瞬间的瞬时长度，若存在其他 goroutine 同时收发数据，则该值可能立即失效，不可用于条件判断或同步逻辑。
在 Go 语言中，len(ch) 对 channel 的调用是原子且无副作用的操作——它不会阻塞、不会修改 channel 状态，也不会触发调度器干预。因此，从运行时实现角度看，该操作是线程（goroutine）安全的，无需额外加锁或同步。
ch := make(chan int, 10)
go func() { ch <- 1 }()
go func() { <-ch }()
// 以下调用不会 panic 或导致数据竞争
fmt.Println(len(ch)) // 安全：输出 0 或 1，取决于执行时机⚠️ 但关键在于：“安全”不等于“可靠”。len(ch) 返回的是调用时刻缓冲区中已发送但尚未接收的元素个数（对无缓冲 channel 恒为 0）。由于 goroutine 调度的不确定性，该值在读取后毫秒内就可能被其他 goroutine 的 send/receive 操作改变。例如：
if len(ch) > 0 {
x := <-ch // ❌ 危险！此处可能阻塞（若 len 返回 1 后另一 goroutine 先取走）
}此类“检查后使用”（check-then-use）模式存在典型的竞态窗口，属于逻辑级竞态（logical race），即使 go run -race 也无法检测。
✅ 正确做法是：
- 使用
select配合default实现非阻塞尝试接收：select { case x := <-ch: // 成功接收 default: // 缓冲为空，不阻塞 } - 若需协调多个 goroutine 的行为，请依赖 channel 本身作为同步原语（如信号 channel、done channel），而非轮询
len()。
? 总结：len(channel) 是语法合法、运行时安全的操作，但它的值不具备同步语义。它适用于调试日志、监控指标（如 Prometheus exporter 中采集瞬时队列深度），绝不应用于控制流决策。真正可靠的并发协调，始终应基于 channel 的通信机制与 select 的原子选择语义。
