因为多个生产者并发写入时执行顺序不可预测，若任一生产者提前关闭通道，其余生产者将panic。

为什么不能由某个生产者直接 close(ch)

因为多个生产者并发写入时，谁先执行完、谁后执行完不可预测。如果第一个生产者写完就 close(ch)，后面其他生产者继续 ch 就会 panic：send on closed channel。

• 错误现象：程序崩溃，报 panic: send on closed channel
• 正确做法：用 sync.WaitGroup 跟踪所有生产者，等它们全部调用 wg.Done() 后，再由一个独立 goroutine 执行 close(ch)
• 不能在主 goroutine 里 wg.Wait(); close(ch) —— 这会阻塞主线程，消费者无法并行启动
• 必须确保关闭动作发生在“所有生产者退出之后、但消费者仍在读取期间”

带缓冲 channel 的大小怎么选才不翻车

缓冲区不是越大越好，也不是越小越安全；它本质是内存与吞吐的权衡点。

• make(chan int, 1) 等价于无缓冲 channel，退化为同步模式，吞吐低、易卡死
• make(chan int, 1000) 可能导致任务积压、OOM 或延迟不可控（比如消费者卡住，1000 个任务全堆在内存里）
• 推荐估算公式：缓冲大小 ≈ 每秒峰值任务数 × 平均处理耗时 × 安全系数（1.5~2）
  例如：每秒最多 20 个任务，平均处理 100m

  

  s → 建议 make(chan Task, 5) 到 make(chan Task, 10)
• 若需丢弃旧任务，必须用 select { case ch ，不能依赖缓冲自动淘汰

消费者用 for range ch 就够了吗

够，但前提是 channel 关闭时机绝对正确。否则 range 会永远阻塞，或提前退出漏数据。

• for data := range ch 是最简洁安全的写法 —— channel 关闭后自动退出循环，无需手动检查 ok
• 但它的前提：channel 必须由生产者侧统一关闭，且关闭前所有数据已成功发送（不是“发了一半就关”）
• 多个消费者共用同一个 ch 时，range 不会造成竞争，Go runtime 保证每个值只被一个消费者收到
• 若需等待所有消费者退出（比如做 cleanup），得另起一个 sync.WaitGroup 管理它们，不能复用生产者的 wg

真实项目里绕不开的三个增强点

裸 channel 只解决通信，不解决健壮性。上线前至少补这三块：

• 超时控制：生产者发数据前加 select { case ch
• 上下文取消：把 context.Context 传给消费者，在处理任务时用 ctx.WithTimeout 防止单任务卡死整个 worker
• 错误反馈通道：消费者处理失败时，往另一个 chan error 发送错误，主 goroutine 统一收集重试或告警；别让错误静默消失

最容易被忽略的是「关闭 channel 的 goroutine 是否真的跑完了」——它没有返回值、不参与 WaitGroup，一旦 panic 或逻辑错，整个流程就卡死在 range 里，连日志都打不出来。