Go close多个发送方共享通道的协调方案

多个 goroutine 往同一个 Go channel 发送数据时，最稳妥的做法不是让“最后一个看起来完成的发送方”负责关闭，而是把关闭权交给发送方之外的协调者：发送方各自调用 Done()，协调者等待 WaitGroup 归零后统一 close(ch)。这样既不会在仍有发送动作时关闭，也不会让多个 goroutine 竞争关闭权。

先确定唯一关闭责任

Go 规范把 close(ch) 定义为“记录不会再有值发送到这个 channel”。它不是“通知其他 goroutine 赶紧结束”的万能锁：向已关闭的 channel 发送、再次关闭同一个 channel，都会触发运行时 panic。因此，多个发送方共享一个输出通道时，关闭者应当位于发送方集合之外。

下面这张结构说明图把职责拆开：producer 只发送并报告完成，WaitGroup 只负责计数，closer 是唯一拥有关闭动作的角色，consumer 只读取。图中的连线表达静态职责关系，不是运行截图或执行时序。

用 WaitGroup 等待发送方结束

关键细节有两个：所有正数 Add 都要在对应 goroutine 启动前完成；每个发送方无论正常返回还是中途出错，都要执行 Done。独立的关闭 goroutine 再调用 Wait，确认计数归零后关闭输出通道。

package main

import (
    "fmt"
    "sync"
)

func produce(id int, out chan

这里不要求接收方提前知道总数据量。WaitGroup 的计数归零只说明发送方都返回了，随后 close(out) 才给接收方一个明确的结束信号。若把 close(out) 放进任一 produce，它返回时其他发送方仍可能执行 out ，这就是典型的 send on closed channel。

让接收方按关闭信号收尾

range out 是消费未知数量结果的自然写法。通道关闭前，接收方继续拿到已经发送的值；关闭后且已发送值读完，循环退出。需要区分“收到零值”和“通道已关闭”时，使用 value, ok := ，不要用业务零值猜测结束。

处理提前退出与动态发送者

如果消费者只需要第一个结果就返回，剩余发送方可能永久阻塞在发送操作上。此时关闭输出通道并不能解决问题，因为关闭者必须先等发送方结束；应增加 done 或 context.Context，让发送方在发送数据和收到取消之间二选一。

func produce(done 

“动态发送者”还要注意注册时机：如果另一个 goroutine 可能在 Wait 已经开始后才调用正数 Add，就不能把它和当前这一轮关闭协调混在一起。先固定发送者集合，再 Add、启动、Wait，边界最清楚；动态任务则应由更高层的任务管理器维护生命周期。

常见问题

多个发送方能不能各自关闭同一个 channel？

不能。关闭权应集中到发送方之外的协调者；否则重复关闭或发送与关闭并发都会产生 panic。

WaitGroup 能不能直接替代 channel 关闭？

不能。它只等待计数归零，接收方仍需要一个结束信号；通常由 Wait 返回后的唯一协调者调用 close。

为什么不直接用固定次数接收？

固定次数把发送方数量和每个发送量硬编码到接收端，异常返回时容易永久等待；关闭协议能把结束条件放在数据生产边界。

判断这类代码是否安全，可以只检查三件事：谁拥有关闭权、所有发送方是否在关闭前完成、消费者提前退出时发送方是否能被取消。三项都明确，多个发送方共享 channel 才不会把收尾责任变成竞态。