多个 Goroutine 都会发消息时，谁负责关闭 Go Channel 才不会 panic

多个 Goroutine 同时向一个 Go Channel 发送数据时，关闭动作不能交给“最后一个看起来发完的人”。最稳的规则是：发送方只负责发送，另设一个协调者等待所有发送方结束，再由它执行唯一一次 close(ch)。这样接收方可以用 range 正常收尾，也不会因为重复关闭触发 panic。

当有多个 Goroutine 同时往同一个 Channel 发送数据时，不能让任意一个发送协程擅自关闭通道，也不能由接收端贸然关闭还在写入的通道，只要没确认所有发送动作全部完成就执行关闭操作，后续还在发消息的协程就会触发 panic。

先定规则：发送方不等于关闭方

Channel 的关闭表示“后面不会再有值”，不是“当前没有值”。因此关闭责任应该交给能证明全部发送都结束的角色。单发送者可以自己关闭；多发送者则不应让每个 worker 都执行 close，也不应让接收方抢着关闭。

常见错误是把“某个 worker 做完了”当成“所有 worker 都做完了”。另一个错误是用 len(ch) 猜测发送是否结束：缓冲区为空只说明此刻没有待收数据，并不能证明未来没有发送。

用 WaitGroup 把关闭动作放到发送方集合之后

把发送者放进 WaitGroup，启动一个只负责收尾的 Goroutine。它等待计数归零后关闭 channel，接收方则只读不关。

func merge(ctx context.Context, inputs ...

这里的边界很明确：每个转发者只调用一次 Done，协调者只调用一次 close(out)。如果输入全部结束，range merge(ctx, a, b) 会自然退出。

停止接收和提前退出时，先解决阻塞

只补上 close(out) 仍可能泄漏：如果接收方只取前几个结果就返回，发送者可能永远卡在 out 。所以“关闭完成”与“取消当前工作”是两个不同信号。

上面的 ctx.Done() 同时放在读输入和写输出两侧，意味着下游不再消费时，上游可以退出，WaitGroup 最终仍能归零。调用方应使用带超时或可取消的 Context，并在不需要结果时调用取消函数：

ctx, cancel := context.WithCancel(context.Background())
defer cancel()
for v := range merge(ctx, sourceA, sourceB) {
    if shouldStop(v) {
        cancel()
        break
    }
}

不要把“接收方关闭输出 channel”当作停止通知；那会让仍在发送的 Goroutine 触发 send on closed channel。停止通知应由 Context、专用 done channel 或上层生命周期管理。

判断清单：什么时候该换成 done 通知

如果目标只是告诉接收方“所有值都发完了”，由发送侧协调后关闭结果 channel；如果目标是“无论成功失败都停止整条流水线”，增加 Context 取消；如果有多个错误需要汇总，再让一个协调者负责收集错误，不要把关闭责任分散给 worker。

排查 panic 或 Goroutine 数量不回落时，依次问四个问题：谁拥有发送权？谁能证明发送者全部退出？接收方会不会提前返回？每条阻塞发送和输入读取是否都能看到取消信号？这四问比给 close 外面套 recover 更有用，因为 recover 只能隐藏错误，不能修复所有权。

相关问题

只有一个发送者时要不要关闭 Channel？如果接收方需要通过 range 知道结束，通常应由唯一发送者关闭；否则也可以由更高层协调者关闭。

能不能用 mutex 保护 close？互斥锁只能避免并发执行 close，不能证明之后不会再发送，根本问题仍是发送生命周期。

关闭后的 Channel 还能读吗？可以读完缓冲值；缓冲值耗尽后立即得到元素类型的零值和 ok == false，发送则会 panic。

总结：多 Goroutine 写一个 Go Channel 时，把“发送完成证明”和“关闭动作”集中到一个协调者；把“下游不再消费”和“发送完成”分成两个协议，才能同时避免重复关闭、发送到已关闭 channel 和 Goroutine 泄漏。