直接用 chan 无法安全实现多生产者多消费者，因无缓冲 chan 要求收发同步，多生产者易阻塞；且多个生产者共用通道时自行 close 会 panic（close of closed channel）或致数据丢失，必须由单独 goroutine 在所有生产者完成 wg.wait() 后统一关闭。
为什么直接用 chan 无法安全实现多生产者多消费者
因为 Go 的 chan 本身不带缓冲区容量控制和关闭协调逻辑，多个 goroutine 同时 close 同一个 channel 会 panic，而未关闭时消费者可能永久阻塞在 。常见错误是：生产者提前退出但没通知消费者，或消费者读到零值误以为数据结束。
实操建议：
- 永远由生产者（或统一协调者）负责
close(ch)，且仅 close 一次 - 消费者必须用
for v, ok := 循环，不能只靠 <code>range ch—— 因为range在 channel 关闭后自动退出，但若生产者未 close，它就卡死 - 如果需要多个生产者，用
sync.WaitGroup等待全部写完再 close；若生产者数量不确定（如动态增删），改用带哨兵值或额外 done channel
用带缓冲的 chan 控制吞吐但别迷信大小
缓冲通道能缓解生产消费速度不匹配，但设太大等于把背压转移到内存，设太小又容易频繁阻塞。关键不是“够不够”，而是“谁该承担等待成本”。
实操建议：
- 缓冲大小优先按业务单次批量处理量设，比如日志采集每批 100 条，
make(chan *Log, 100)比make(chan *Log, 1024)更易观察积压 - 避免用
len(ch) == cap(ch)判断满——这只能反映快照，且len和cap对 channel 是 O(1) 但非原子，不能替代背压协议 - 真正需要流控时，用
select+default做非阻塞尝试写入，失败则降级（丢弃、重试、告警）
消费者怎么知道所有生产者都结束了
核心难点不在 channel 读取，而在“终结信号”的传递时机。单纯依赖 close 要求所有生产者严格协作，现实中常因 panic、超时或逻辑分支漏掉 close。
实操建议：
- 用
sync.WaitGroup记录活跃生产者数，主 goroutinewg.Wait()后再close(ch)—— 注意wg.Add()必须在 goroutine 启动前调用 - 更健壮的做法是引入第二个 channel：
done chan struct{}，消费者监听select { case v, ok := ，由外部统一发信号 - 不要在消费者内部起 goroutine 去 close channel，这是竞态温床
实际代码里最容易漏掉的三件事
不是语法错，而是语义错：程序看似跑通，但压测时丢数据、卡死、OOM。这些问题往往在本地小流量下完全不暴露。
实操建议：
- 所有向 channel 写入的地方，必须有 recover 包裹或明确的错误处理路径，否则生产者 panic 会导致 channel 永远不被 close
- 消费者启动数量要显式控制（比如
for i := 0; i ），别用 <code>range动态启 goroutine，否则难以限流 - 测试时强制让某个生产者提前 return，看消费者是否 hang 住——这是检验 close 逻辑是否完备的最快方式
