Go 多个发送方共用 channel 时怎么协调安全关闭

多个 goroutine 往同一个 channel 发送数据时，最稳妥的规则是：发送方只负责发送，关闭权交给一个知道所有发送方何时结束的协调者。不要让“最后一个看起来完成的 worker”直接 close(ch)，因为其他 worker 可能仍在执行下一次发送，结果就是 panic: send on closed channel。

先用 sync.WaitGroup 等待全部发送方退出，再由单独的协调 goroutine 关闭数据 channel；如果接收方可能提前结束，再给每个发送方增加 done 或 context.Context 的取消出口。

先固定 channel 的关闭责任

故障通常发生在这样的改造中：原来只有一个生产者，生产者完成后顺手关闭 data；后来为了提高吞吐量，代码启动了三个生产者，却保留了原来的关闭动作。第一个结束的生产者并不知道另外两个是否还会发送，关闭后的下一次发送便会触发运行时 panic。

Go 规范明确规定，向已关闭的 channel 发送会产生运行时 panic，重复关闭也会 panic；关闭的含义是“不再有值发送”。所以“谁创建、谁关闭”不是足够精确的规则，更准确的判断是“谁能证明所有发送动作都结束，谁关闭”。

用 WaitGroup 把最后一个发送方交给协调者

下面的结构把职责拆开：生产者通过只发送方向的 chan 接收发送入口，协调者持有双向 channel 并负责关闭，接收方只拿到 。这样类型方向会把错误的关闭动作尽早暴露出来。

package main

import (
    "fmt"
    "sync"
)

func startWorkers(values []int, workers int) 

这里不需要知道哪个 worker 最后完成。Wait 返回本身就是一个整体判断：所有已经加入 WaitGroup 的发送方都调用了 Done。协调 goroutine 只在这个判断成立后关闭 data，接收方就可以安全地使用 range 读到结束。

接收方提前退出时，发送方也要有出口

自然结束和提前取消是两条不同路径。若接收方只取第一个结果就返回，而生产者仍在向无缓冲 channel 发送，生产者会卡在发送表达式，Wait 永远不会返回，关闭协调者也就无法工作。

func send(done 

生产者循环里应把每次发送都放进类似的 select。取消信号只负责让发送方退出，不负责关闭 data；WaitGroup 仍然负责等它们退出，最后由同一个协调者关闭数据 channel。这个分工能避免把“停止生产”“所有生产者已停止”“数据 channel 已关闭”三个状态混为一谈。

用 value、ok 区分自然收尾和异常退出

接收方需要判断结果来源时，不要只检查读到的值是否为零值，因为零值也可能是业务数据。使用双返回值接收：value, ok := 。当 channel 尚未关闭时，ok 为 true；关闭且历史值已经读完后，ok 为 false。

for {
    value, ok := 

排查线上 panic 时可以按这个顺序看：是否有多个位置调用 close；是否有 worker 在协调者关闭后仍可能发送；接收方是否提前返回而没有广播取消；WaitGroup.Add 是否发生在启动 goroutine 之前。四项中任何一项失控，关闭时序就不再可靠。

常见问题

能不能用 recover 避免 send on closed channel？

不建议。recover 只能吞掉已经发生的运行时错误，不能恢复丢失的数据，也不能证明其他发送方已经退出。修正关闭所有权和等待关系才是根因处理。

多个发送方结束后，接收方一定要关闭 channel 吗？

如果接收方拥有发送方生命周期并能证明不会再发送，可以关闭；但在共享发送模型中，更适合由等待所有发送方的协调者关闭。接收方通常只读，不抢占关闭权。

done channel 和 data channel 能不能是同一个？

不要混用。data 表示业务值流，done 表示取消广播，类型和生命周期都不同。拆成两个 channel 后，接收、关闭和取消的责任更容易检查。

多发送方 channel 的关键不是找一个“最晚完成”的 worker，而是建立唯一关闭者、完整等待链和可取消的发送路径。把这三件事分开，send on closed channel 与 goroutine 泄漏通常就能同时消失。