Go 如何设计 channel 关闭责任避免发送方 panic

Go 里最容易把 channel 关闭写错的场景，不是“忘了 close”，而是多个 goroutine 都觉得自己有权 close，或者接收方提前退出后，发送方还在继续发送。只要发送动作和关闭动作没有同一个生命周期负责人，就可能出现 send on closed channel panic。

实用规则是：谁能确定“后面不会再有发送”，谁负责关闭；如果有多个发送方，就先让它们统一退出，再由一个协调者关闭；取消任务则单独关闭 done/context 信号，不拿数据 channel 充当取消开关。

先判断谁拥有发送结束信息

close(ch) 的含义是“不会再向 ch 发送值”。因此判断责任人时，不要按“谁拿到了 channel”决定，而要按“谁知道所有发送已经结束”决定。Go 规范明确规定，向已关闭 channel 发送会触发运行时 panic；重复关闭也会 panic。接收方可以观察关闭，却通常无法知道其他发送方是否还有最后一条消息。

可以先用这张清单做设计判断：

用单发送方封装建立关闭责任

最简单的安全形态，是函数内部创建 channel，并只把接收方向交给调用方。这样调用方无法调用 close，生产者也能把“最后一次发送之后关闭”放在同一处。

// 生产者拥有 out 的发送和关闭责任，调用者只能接收。
func numbers(values []int) 

defer close(out) 适合这个例子，是因为只有这个 goroutine 发送，且函数退出就意味着不会再发送。若发送可能因取消提前返回，也应让发送循环和关闭动作仍在同一个生产者生命周期中。

多发送方先协调完成再关闭

多个 goroutine 共同发送时，下面这种写法很危险：

// 错误示例：两个发送方都可能执行 close，导致重复关闭。
go func() { defer close(out); out 

正确做法是把 close 从发送 worker 中移出。worker 只负责发送和报告完成，协调者等待全部 worker 结束后再关闭：

// 每个 worker 只发送数据，不拥有 close 责任。
func fanIn() 

这里的关键不是 WaitGroup 本身，而是关闭动作必须发生在“全部发送完成”的事实之后。生产代码还要处理接收方提前退出：让 worker 在发送处同时监听取消信号，否则它们可能因无人接收而泄漏。

把取消信号和数据 channel 分开

如果接收方只想要第一条结果就返回，直接关闭结果 channel 并不能安全地阻止仍在运行的发送方，反而会让后续发送 panic。取消应该使用单独的 done 或 context.Context，发送者用 select 在“发送结果”和“收到取消”之间选择。

// done 只表达取消，不承担结果 channel 的关闭责任。
func sendResult(done 

若使用 context.WithCancel，由启动这组并发工作的上层持有 cancel 函数；下层只接收 ctx.Done()。数据 channel 的关闭仍由真正拥有发送结束信息的一方完成。取消和关闭分别表达“现在停止工作”和“以后不再有值”，语义不会混在一起。

常见问题

接收方能不能负责关闭 channel？

语法上能，但除非接收方同时拥有全部发送生命周期，否则设计上不应这么做。它无法证明发送方已经停止，容易造成发送 panic。

用 recover 能不能解决 send on closed channel？

recover 只能截住已经发生的 panic，不能修复关闭责任竞争，也可能掩盖数据丢失。应先重画发送、关闭和取消的边界。

不 close channel 会怎样？

如果接收方使用 range，没有关闭就无法自然结束，可能留下阻塞 goroutine。若 channel 只是一次性信号且生命周期由 context 管理，则可以不把 close 当作数据协议的一部分。

设计 channel 时，最后只检查三件事：是否只有一个关闭者、关闭前是否确认所有发送者结束、接收方提前退出时是否有独立取消路径。三项都明确，发送方 panic 通常就能在代码评审阶段消失。