能，len() 返回通道当前缓冲区中已排队的元素数量，cap() 返回其缓冲区总容量；对无缓冲通道，cap() 恒为0，len() 几乎总为0，二者均为瞬时快照，不可用于阻塞判断。
len() 和 cap() 能直接用在 channel 上吗
能，但必须清楚它们返回的是什么——len() 返回当前通道中已排队的元素个数，cap() 返回通道缓冲区的容量（仅对带缓冲通道有意义）。对无缓冲通道，cap() 恒为 0。
为什么 len(ch) 不是“剩余可用空间”
这是最常见的误解：len(ch) 不是还能塞几个元素，而是“已经塞进去、还没被取走”的数量。比如一个 make(chan int, 10) 的通道，刚创建时 len(ch) 是 0，写入 3 个后变成 3，此时还能再写 7 个，但这个“7”得靠 cap(ch) - len(ch) 算出来，不是 len() 本身提供的。
-
len(ch)是运行时状态快照，不是原子操作，多 goroutine 并发读写时值可能瞬变 - 对无缓冲通道（
make(chan int)），len()只有在发送/接收恰好卡住的瞬间才可能非零（极难观测），绝大多数时候是 0 - 不能靠
len(ch) == 0判断通道是否“空闲可写”，因为写操作可能阻塞，而len()并不反映阻塞状态
实际检查通道状态的可靠方式
想判断能否立即发送或接收，唯一安全的方式是用 select 配合 default 分支：
select {
case ch <- 42:
// 成功发送
default:
// 通道满（带缓冲）或无缓冲且无接收者等待，无法立即发送
}- 不要用
len(ch) 替代 <code>select—— 两者之间存在竞态：你刚算完条件成立，另一 goroutine 就把通道填满了 -
len()和cap()适合做监控或调试（如打印当前积压量），不适合做控制流决策 - 如果通道用于任务队列，更合理的指标是业务层记录的待处理数，而不是依赖
len(ch)
cap(ch) 对无缓冲通道永远是 0
无缓冲通道本质是同步通信点，没有存储空间，所以 cap() 定义上就是 0。试图用 cap(ch) 区分通道类型会出错：
立即学习“go语言免费学习笔记（深入）”；
ch1 := make(chan int) // cap(ch1) == 0 ch2 := make(chan int, 0) // cap(ch2) == 0 —— 这和 ch1 完全等价 ch3 := make(chan int, 5) // cap(ch3) == 5
-
make(chan T, 0)和make(chan T)是同一回事，别误以为前者“预留了容量” - 不能靠
cap(ch) > 0判断通道是否带缓冲——它只告诉你“有没有缓冲区”，但无法区分“缓冲区大小是否足够应对当前负载” - 一旦创建，通道的
cap()就固定不变，无法扩容或缩容
实际用 len() 和 cap() 前，先问自己：我到底需要知道什么？是调试积压量，还是想绕过阻塞逻辑？后者必须用 select，前者才轮得到这两个函数。
