Go 语言中 channel 实现生产者消费者模型

直接用 Go 的 chan 实现多生产者多消费者，看着简单，坑却不少。无缓冲的通道要求收发必须同步，多个生产者如果同时写，很容易因为发不出去而阻塞；更头疼的是关闭问题——多个生产者如果各自尝试 close，要么 close of closed channel 直接 panic，要么数据没写完就关了导致消费者读到不完整的流。行业里常见的解法是让一个单独的 goroutine 在所有生产者通过 sync.WaitGroup 统一完成后，再执行 close 操作。

为什么直接用 chan 无法安全实现多生产者多消费者

因为 Go 的 chan 本身只负责消息传递，不负责协调关闭和生命周期。多个 goroutine 同时 close 同一个通道会触发 panic，而如果不关闭，消费者又可能永远阻塞在 range 上。常见的错误是：生产者提前退出了但没通知消费者，或者消费者读到零值以为数据结束了，但其实生产者还没写完。

实操建议：

• 永远由生产者（或一个统一的协调者）负责 close(ch)，且只关一次。
• 消费者必须用 for v, ok := <-ch { 这种带 ok 判断的循环，不能只靠 range——range 在通道关闭后自动退出，但若生产者没关，它就永远卡在那里。
• 如果需要多个生产者，用 sync.WaitGroup 等待全部写完再 close；如果生产者数量动态变化（比如动态增删），改用额外哨兵值或一个专门的 done channel。

用带缓冲的 chan 控制吞吐但别迷信大小

缓冲通道确实能缓解生产消费速度不匹配，但设得太大会把背压转移到内存里，设太小又频繁阻塞。关键不是“容量够不够大”，而是“谁该承担等待的成本”。

实操建议：

• 缓冲大小优先按业务单次批量处理量来设。比如日志采集每批 100 条，make(chan *Log, 100) 就比 make(chan *Log, 1024) 更容易观察到积压情况。
• 不要用 len(ch) == cap(ch) 判断通道是否满——这个快照值既不原子也无法反映真实背压，不能替代流控协议。
• 真正需要流量控制时，用 select + default 做非阻塞尝试写入，失败则降级（比如丢弃、重试或告警）。

消费者怎么知道所有生产者都结束了

这个问题的核心不在 channel 读取本身，而在于“终结信号”的传递时机。单纯依赖 close 要求所有生产者严格协作，但现实里经常因为 panic、超时或逻辑分支漏掉了 close。

实操建议：

• 用 sync.WaitGroup 记录活跃生产者数，主 goroutine 在 wg.Wait() 之后再 close(ch)——注意 wg.Add() 必须在 goroutine 启动前调用。
• 更健壮的做法是引入第二个 channel：done chan struct{}，消费者通过 select { case v, ok := <-ch: ...; case <-done: return } 来监听，由外部统一发信号。
• 不要在消费者内部起 goroutine 去 close channel，这是竞态的温床。

实际代码里最容易漏掉的三件事

不是语法错误，而是语义错误——程序在本地小流量下跑得稳稳的，压测一上就开始丢数据、卡死甚至 OOM。这些问题往往只有压力下才暴露。

实操建议：

• 所有向 channel 写入的地方，必须有 recover 包裹或明确的错误处理路径。否则一个生产者 panic 会导致整个 channel 永远不被 close，所有消费者死锁。
• 消费者数量要显式控制（比如 for i := 0; i < n; i++ { go consumer() }），不要用 range 动态起 goroutine，那样很难限流。
• 测试时强制让某个生产者提前 return，观察消费者是否会一直 hang 住——这是检验 close 逻辑是否完备的最快方法。

说到底，channel 的边界很清晰：它只负责传递数据，不负责生命周期管理。把关闭、错误传播、goroutine 结束这些事硬塞给 channel，迟早要踩坑。一套清晰的协调模式（比如 WaitGroup + 统一 close）才是长期稳定的基础。