Go 多个生产者场景怎么安全决定谁负责关闭 channel

多个 goroutine 往同一个 channel 发送时，最稳的规则只有一句：生产者负责发送，唯一的协调者负责关闭，接收者只负责读取。不要让每个生产者在“我结束了”时顺手 close，也不要让接收端猜哪个发送者最后退出。关闭权一旦集中，发送 panic 和关闭后的零值就都有了明确边界。

多个生产者时先固定关闭方向

Go 规范把 close 视为发送方发出的“不会再有值”的信号。这个模型在单生产者时很直观，但多个生产者共享一个输出 channel 时，任何一个生产者都无法证明其他生产者已经结束。因此，关闭者应该是知道全局状态的协调者，而不是局部完成的生产者。

下面的写法把 close(out) 放在所有生产者退出之后。Add 先完成，避免协调 goroutine 看到尚未登记的生产者。

func merge(inputs ...

接收端可以直接 range merge(...)，因为协调者会在最后一个生产者完成后关闭输出。这里的“最后”不是某个生产者自报，而是 Wait 对全部生产者状态的汇总。

旧写法为什么会把发送 panic 藏进并发竞态

常见错误是每个生产者都写一段 defer close(out)。第一个退出的 goroutine 关闭了 channel，其他生产者稍后执行 out 就会 panic；如果其他生产者也退出，重复关闭还会再次 panic。把 close 包在 recover 里，只能掩盖症状，不能恢复丢失的数据或修复责任协议。

关闭、零值和发送 panic 的边界

从 channel 接收时，value, ok := 才能把“收到一个值”和“channel 已关闭”区分开。关闭后的接收会返回元素类型的零值，同时 ok 为 false；如果业务本身允许发送 0、空字符串或 nil 指针，单看 value 就会误判。

for {
	value, ok := 

如果接收端使用 for value := range out，语言会替你处理这个判断；但在需要区分结束原因或记录统计时，显式的 ok 更清楚。关闭方向仍不变：发送方不会再发送，协调者只在确认全部发送完成后关闭。

采用前用一张责任清单复查

• 共享 channel 是否只有一个明确的关闭者？
• 所有生产者是否在创建 goroutine 前完成 WaitGroup.Add？
• 生产者提前返回时是否仍会执行 Done？
• 接收端是否用 ok 或 range 判断结束，而不是比较零值？
• 是否存在另一个 goroutine 仍可能在关闭后发送？如果存在，关闭时机仍然不安全。

常见问题

多个接收者可以共同决定关闭 channel 吗？

不建议。接收者通常只消费数据，不掌握所有生产者是否结束；应由协调者集中关闭。

关闭 channel 后还能读取剩余缓冲值吗？

可以。已关闭的带缓冲 channel 仍会先返回缓冲区中的有效值，缓冲耗尽后才返回元素零值和 ok=false。

能不能用 select 先探测 channel 是否关闭？

不能把探测当成关闭协议。探测与真正发送之间仍可能发生竞态，可靠做法仍是让关闭者唯一且等待全部生产者退出。