多个生产者不能各自close(channel)，因为channel只能关闭一次，重复调用会panic: close of closed channel；竞态下无法协调关闭时机，易导致数据截断或消费者提前退出；sync.WaitGroup提供可靠、原子的完成等待机制，确保主goroutine在所有生产者退出后唯一、终局性地关闭channel。
多生产者场景下，仅靠 close(ch) 无法安全退出消费者循环，必须由主 goroutine 在所有生产者结束后统一关闭通道。
为什么多个生产者不能各自 close(channel)
Go 的 channel 只能被关闭一次，第二次调用 close() 会直接 panic：panic: close of closed channel。多个 goroutine 竞争关闭，既无顺序保障，也无法判断谁该关、何时关。即使加锁或原子计数，也绕不开“谁负责最终关闭”这个协调问题——而 sync.WaitGroup 正是为此设计的：它把“等待全部完成”这件事抽象为可组合、可复用的同步原语。
- 每个生产者只做两件事：
ch 和 <code>wg.Done()，不碰close - 主 goroutine 调用
wg.Wait()后，才执行close(ch)，确保关闭动作是单点、终局、无竞争的 - 消费者使用
for result := range ch安全退出，因为 range 退出条件明确：通道已关闭且缓冲区/队列为空
缓冲通道大小到底影响什么
make(chan T, N) 中的 N 不是并发数上限，也不是吞吐加速器，它只是声明“我允许最多 N 个未处理任务积压”。实际并发行为由调度和接收节奏决定。
-
N = 0（无缓冲）：每次ch 都阻塞，直到有 goroutine 执行 <code><-ch；适合强同步信号场景，比如 handshake 或初始化完成通知 -
N = 1：至少缓存一个结果，避免生产者因消费者瞬时卡顿而停摆；常见于简单工作池，但不解决背压问题 -
N > 1：仅扩大积压边界，若消费者长期跟不上，内存持续增长，最终 OOM；它不自动限流，也不触发拒绝策略
消费者如何避免漏数据或提前退出
range 退出时机依赖通道关闭 + 缓冲清空，但这两个条件容易被误判。常见错误包括：
立即学习“go语言免费学习笔记（深入）”；
- 生产者 panic 或提前 return，没发完数据就退出，导致部分任务丢失
- 主 goroutine 在
wg.Wait()前就 close(ch)，消费者 range 提前结束，剩余缓冲数据被丢弃 - 消费者未用
for range，而是用<-ch单次接收，遗漏后续值
正确做法是：确保所有生产者都 defer wg.Done() 或显式调用；主 goroutine 必须在 wg.Wait() 返回后立即 close(ch)；消费者必须用 for x := range ch —— 这三者缺一不可。
带超时的消费者怎么写才不漏信号
如果消费者需要限时处理，不能简单套 select { case x := ，否则可能错过刚进缓冲区但尚未被 range 拿到的值。更稳的方式是用独立 goroutine 关闭通道，并配合 context 控制整体生命周期：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
<p>go func() {
wg.Wait()
close(results)
}()</p><p>for {
select {
case r, ok := <-results:
if !ok {
return // 通道关闭，安全退出
}
handle(r)
case <-ctx.Done():
return // 超时退出，此时可能还有未读数据，但业务要求止损
}
}注意：这里 ctx.Done() 是中断整个消费流程，不是替代 channel 关闭；它不保证已发送但未读取的数据被处理，这是业务权衡点，不是 bug。
真正难的不是写对一段代码，而是理解“谁关通道”“谁等完成”“谁负责兜底”这三件事必须解耦、角色分明。一旦让生产者自己关通道，或让消费者去数接收次数，就等于放弃 Go 并发模型里最可靠的那个支点。
