Go channel向已关闭通道发送触发panic的责任划分

Go 里向已关闭的 channel 发送值会触发运行时 panic，重复调用 close 也一样危险。真正需要修正的通常不是某一行发送代码，而是关闭责任分错了：接收方知道“我不想再收”，却不一定知道所有发送方是否已经结束。更稳的约定是：谁能确认不会再发送，谁负责关闭；接收方只消费，不主动 close。

把关闭权交给发送生命周期的拥有者，并保证整个程序只有一个关闭出口，就能从根上避免 send on closed channel。多发送方场景则先等待所有发送者退出，再由协调者关闭。

Go channel 的关闭责任先看发送链路

channel 有三类动作：发送、接收和关闭。发送方掌握“是否还会产生值”，所以最适合判断结束时机；接收方只能知道当前没有值，不能据此断定未来不会再有值。这个区别正是许多 panic 的来源。

关闭后的接收行为不能反推关闭权

关闭不是把 channel 里的值清空。缓冲 channel 仍会按顺序交付已经发送的值，值取完后接收操作才返回元素类型的零值；使用双返回值接收时，第二个值为 false。因此“接收方可以安全地读到结束”不等于“接收方应该负责 close”。

for {
	value, ok := 

如果只关心所有值都处理完，也可以使用 for value := range ch。但不要用 recover 把发送 panic 当成正常流程；它最多隐藏责任竞态，无法证明关闭顺序正确。

多发送方迁移为统一收口

当多个 goroutine 都向同一个 channel 发送时，任何一个发送者都不适合直接 close：它无法证明其他发送者已经停止。可以让协调者等待发送组完成，再执行唯一一次关闭；发送者同时监听取消信号，避免收件人提前退出后继续阻塞。

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

这里的关键不是 WaitGroup 本身，而是“发送者不关闭共享输出，协调者只在发送组归零后关闭”。如果只有一个生产者，可以直接由它在生产循环结束处 defer close(out)；如果有多个生产者，必须保留一个统一收口点。

上线前检查这份 channel 清单

• 关闭者是否明确知道全部发送任务已结束？如果不知道，就不要让它 close。
• 发送端是否在取消路径上停止向下游写入？否则接收方退出后可能永久阻塞。
• 下游是否只拿到 ？只读类型能在接口层减少误关闭。
• 是否存在两个 defer、两个协调 goroutine 或两个错误分支都调用 close？保留一个出口。
• nil channel 是否被误当成已关闭 channel？nil channel 的发送和接收都会永久阻塞，关闭 nil channel 则会 panic。

排查时先画出“谁发送、谁等待、谁关闭、谁接收”的关系，再看代码。只要关闭者没有发送生命周期的完整信息，优先调整职责，而不是给发送点套恢复逻辑。

常见问题

接收方提前退出时可以直接关闭 channel 吗？

不建议。提前退出只代表当前消费者不再读取，不能证明其他发送者已停止。应通过 context、done channel 或明确的取消协议通知发送方收口。

关闭后的 channel 还能读取吗？

可以。已发送的值会先被读出；值耗尽后，双返回值接收会得到零值和 ok=false。这就是消费者自然结束的信号。

官方语义可参考：https://go.dev/ref/spec#Channel_types 与 https://go.dev/ref/spec#Close。