cap(ch) 返回通道缓冲区总容量，是创建时确定的固定值；len(ch) 返回当前缓冲区中排队的元素数量，二者需配合使用才能判断水位状态。
cap(ch) 返回的是通道缓冲区容量，不是当前消息数
很多人第一次看到 cap 用在通道上，会误以为它能反映“还有多少消息没被消费”，其实完全相反：cap(ch) 只返回创建通道时指定的缓冲大小，是个固定值。比如 make(chan int, 10) 创建的通道，无论你发了 0 条、5 条还是 10 条，cap(ch) 永远是 10。
这个值在运行时不会变，也不受发送/接收操作影响。它只在 make 调用时确定，之后就是只读的配置项。
- 无缓冲通道（
make(chan T)）的cap恒为0 - nil 通道的
cap也是0，但访问 nil 通道会 panic，所以调用前需确保通道已初始化 -
cap和len是唯一两个能安全作用于通道的内置函数；其他如close是操作，不是查询函数
cap(ch) 和 len(ch) 必须配合使用才有实际意义
单独看 cap(ch) 只知道“最多能塞多少”，单独看 len(ch) 只知道“现在塞了多少”。只有两者一起看，才能判断缓冲区水位：
比如 len(ch) == cap(ch) 表示缓冲区已满，下一次发送将阻塞（除非用 select + default 非阻塞发送）；len(ch) == 0 且 cap(ch) > 0 表示缓冲区空但可用，发送不会阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 监控场景常用组合：
float64(len(ch)) / float64(cap(ch))算出填充率，用于告警或自动扩缩容决策 - 注意：这两个值都是瞬时快照，高并发下可能刚读完就变了，不能用于原子性控制逻辑（比如“如果没满才发”这种 if 判断不可靠）
- 调试时建议打日志：
fmt.Printf("ch: len=%d, cap=%d\n", len(ch), cap(ch))，比单看一个值更有上下文
cap(ch) 对通道行为没有 runtime 影响，但决定阻塞边界
cap 本身不参与调度，Go 运行时也不会因为 cap 值不同而改变 goroutine 调度策略。但它直接定义了发送操作何时开始阻塞：
- 当
len(ch) ：发送立即成功，数据入缓冲队列 - 当
len(ch) == cap(ch)：发送 goroutine 阻塞，直到有接收者腾出空间 - 对无缓冲通道（
cap(ch) == 0），发送永远等待接收方就绪，等价于len(ch) == 0时也必须阻塞
这意味着，如果你观察到某个通道频繁阻塞，先查 cap(ch) 是否过小，再结合 len(ch) 的典型值判断是否需要扩容——而不是试图用 cap 去“触发”某种行为。
别把 cap(ch) 当作性能优化开关
有人会想：“把 cap 设得特别大，是不是就能避免阻塞、提升吞吐？” 实际上这是个危险思路：
- 过大的
cap会导致内存占用不可控，尤其当元素是大结构体时，缓冲区可能吃掉几百 MB - 高缓冲容量掩盖了消费者处理慢的真实问题，让瓶颈从“阻塞”变成“内存溢出”或“延迟飙升”
- Go 的 channel 底层用环形队列实现，
cap过大会增加 cache miss 概率，反而降低吞吐
真正该关注的是：消费者处理速度是否匹配生产者节奏？缓冲区是否在合理水位震荡？cap 只是配合这个节奏的配置参数，不是万能加速器。
