无缓冲 channel（cap=0）仅适用于强同步、低吞吐且消费者绝对不卡的场景，如信号通知、goroutine 握手等；一旦消费者延迟或缺失，生产者立即阻塞，导致死锁或协程挂起。
缓冲区容量不是越大越好，也不是越小越安全；设错会直接让背压失效、内存暴涨或吞吐骤降。
cap=0 无缓冲 channel 什么时候能用
只适合强同步、低吞吐、且消费者绝对不卡的场景，比如发一个信号通知、做一次握手。生产者 ch 会卡死直到有消费者执行 <code>，一旦消费者延迟或 panic，所有生产者 goroutine 就挂起不动。
- 多个生产者共用一个
make(chan T, 0)是高危操作：哪怕只有一个消费者，瞬时并发写入也会集体阻塞 - 无法缓解生产/消费速率差，等于把“等”这件事完全交给调用方，不适合 pipeline 类任务
- 调试时看到大量 goroutine 停在
chan send状态，八成是这里卡住了
带缓冲 channel 的容量怎么算才靠谱
别拍脑袋填 1024 或 4096。合理值 ≈ 预期峰值并发量 × 单次批处理量。例如日志采集器每秒最多涌进 100 条、每条平均处理耗时 50ms，则理论积压余量是 100 × (50 / 1000) ≈ 5 条——实际设为 16 或 32 更利于暴露问题。
- 多个生产者时，峰值并发量 = 生产者数 × 每个生产者的最大并发写入数（如 5 个生产者 × 20 条 = 100）
- 单次批处理量指消费者一次
for range或批量select处理的数据条数，不是单条数据大小 -
len(ch)返回当前未读元素数，cap(ch)才是总容量；剩余空间得自己算：cap(ch) - len(ch)
缓冲区太大反而掩盖真实瓶颈
当 len(ch) 长期 > 80% cap(ch)，说明消费者已跟不上，但程序还在“假装正常”运行。运维看到告警时，可能已有数千任务积压在内存里。
- 监控不能只看
len(ch) == cap(ch)—— 这只是快照，且非原子，无法替代流控逻辑 - 真正需要背压响应时，要用
select+default做非阻塞写入：select { case ch - 缓冲区本质是把“等待成本”从 goroutine 切换转移到内存占用，设大了只是延后暴露问题
消费者变慢时，容量如何影响行为暴露节奏
容量太小，背压来得太急：burst 流量下频繁触发 select 超时或重试风暴；容量太大，背压来得太迟：消费者延迟升高后，要等好几分钟才填满 channel，问题定位严重滞后。
- 建议在关键 pipeline 中加周期性检查：
if float64(len(ch))/float64(cap(ch)) > 0.7 { log.Warn("channel fill ratio high") } - 不要依赖消费者自己 close channel —— 容易漏关、重复关或竞态关；必须由统一协调者（如
sync.WaitGroup等待后）调用close(ch) - 最容易被忽略的是：所有写入点都要有错误兜底，否则压测时丢数据、OOM、goroutine 泄漏全靠运气才暴露
