因为关闭channel的唯一安全主体是发送方，且必须确保所有发送操作彻底完成后再关闭；若任一生产者提前关闭，其余生产者继续向已关闭channel发送数据将触发panic: send on closed channel。
不能靠某一方单方面关闭，必须协调所有生产者退出后，由唯一协程关闭 channel。
为什么不能在任意生产者里 close(ch)
多个生产者 goroutine 同时向 ch 发送数据，如果其中某个提前调用 close(ch)，其余还在运行的生产者继续执行 ch 就会触发 panic。Go 语言明确禁止对已关闭 channel 再次写入——这不是竞态，是直接崩溃。
- 消费者无法判断 channel 是否真“空了”，因为可能有其他生产者还没发完
- 用
sync.Once或recover包裹close只是掩盖问题，没解决根本逻辑冲突 - 哪怕加锁判断
closed字段，也无法防止“判断完就 panic”的时间窗口
推荐做法：用 WaitGroup + 单独关闭协程
让每个生产者在退出前通知“我干完了”，等全部完成再统一关 channel。消费者只管读，直到 ok == false 自然退出。
- 声明
var wg sync.WaitGroup和done := make(chan struct{})（可选，用于通知关闭完成） - 每个生产者启动前
wg.Add(1)，结束前wg.Done() - 起一个新 goroutine：
go func() { wg.Wait(); close(ch) }() - 消费者无需做任何特殊处理，
for x := range ch会自动在close(ch)后退出
如果生产者永不主动退出（比如监听网络连接）怎么办？
这时不能依赖 WaitGroup，得换信号驱动方式：用一个额外的 shutdown channel 或 context.Context 让所有生产者感知“该停了”。
- 每个生产者循环内加
select { case - 关闭时调用
cancel()，所有生产者陆续退出 - 再用
WaitGroup等它们全部退出后，才close(ch) - 注意：不要用
context.WithCancel的 cancel 函数去关 channel，它只是通知，不是替代close
最容易被忽略的一点
消费者数量不影响关闭逻辑，但如果你用了带缓冲的 channel，且生产者退出前还有未消费完的数据，close(ch) 之后消费者仍能读完缓冲区内容——这是正确行为，不是 bug。别为了“立刻退出”而强行用 select 配 default 跳过读取，那会丢数据。
