因为多个生产者并发写入时执行顺序不可预测，若任一生产者提前关闭通道，其余生产者将panic。
为什么不能由某个生产者直接 close(ch)
因为多个生产者并发写入时，谁先执行完、谁后执行完不可预测。如果第一个生产者写完就 close(ch)，后面其他生产者继续 ch 就会 panic：<code>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 个任务，平均处理 100ms → 建议make(chan Task, 5)到make(chan Task, 10) - 若需丢弃旧任务，必须用
select { case ch ，不能依赖缓冲自动淘汰
消费者用 for range ch 就够了吗
够，但前提是 channel 关闭时机绝对正确。否则 range 会永远阻塞，或提前退出漏数据。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
for data := range ch是最简洁安全的写法 —— channel 关闭后自动退出循环，无需手动检查ok - 但它的前提：channel 必须由生产者侧统一关闭，且关闭前所有数据已成功发送（不是“发了一半就关”）
- 多个消费者共用同一个
ch时，range不会造成竞争，Go runtime 保证每个值只被一个消费者收到 - 若需等待所有消费者退出（比如做 cleanup），得另起一个
sync.WaitGroup管理它们，不能复用生产者的wg
真实项目里绕不开的三个增强点
裸 channel 只解决通信，不解决健壮性。上线前至少补这三块：
立即学习“go语言免费学习笔记（深入）”；
-
超时控制：生产者发数据前加
select { case ch -
上下文取消：把
context.Context传给消费者，在处理任务时用ctx.WithTimeout防止单任务卡死整个 worker -
错误反馈通道：消费者处理失败时，往另一个
chan error发送错误，主 goroutine 统一收集重试或告警；别让错误静默消失
最容易被忽略的是「关闭 channel 的 goroutine 是否真的跑完了」——它没有返回值、不参与 WaitGroup，一旦 panic 或逻辑错，整个流程就卡死在 range 里，连日志都打不出来。
