Go 向已关闭 channel 发送时怎么从设计上避免 panic

线上看到 panic: send on closed channel 时，优先检查的不是某个发送语句，而是 channel 的关闭职责。Go 规定：关闭后的 channel 可以继续接收已经缓冲的值，随后接收零值；但任何发送都会触发运行时 panic。因此，安全设计应让发送方只发送，等所有发送方退出后由唯一协调者关闭；接收方提前结束则通过独立的取消信号通知发送方停止。

不要用“能不能先判断 channel 已关闭”解决问题。发送和关闭之间仍可能发生竞态，真正可靠的办法是建立明确的所有权和退出协议。

为什么关闭后的接收安全，发送却会 panic

关闭是一个单向承诺：调用 close(ch) 后，程序声明不会再向 ch 发送值。接收端可以用双返回值判断通道是否结束，但这只说明“没有更多值可读”，并不意味着发送端可以继续试探。

func demo(ch chan int) {
	close(ch)       // 关闭权只能交给确定发送已经结束的一方
	value, ok := 

另外，向 nil channel 发送会永久阻塞，关闭 nil channel 也会 panic。不要把 recover 当成常规控制流；它最多是兜底记录，不能修复关闭时序。

多生产者场景要把关闭权交给协调者

最常见的事故是某个生产者“觉得自己完成了”就关闭公共 channel，另一个生产者随后还在发送。生产者数量不确定时，用 sync.WaitGroup 记录它们的生命周期，关闭动作放在等待结束的单独 goroutine 中。

func produceAll(inputs []int) 

这里的关键不是把 close 写在哪个 goroutine，而是关闭前有可证明的条件：所有发送者都已经返回。若生产者内部还会启动子 goroutine，必须把子 goroutine 也纳入等待范围。

接收方提前退出时，用取消信号停止发送

接收方可能只需要前几个结果，或者请求已经超时。此时直接关闭数据 channel 会与仍在工作的生产者竞争；更稳妥的方式是关闭独立的 done channel，让发送方在发送和取消之间选择。

func send(ctx context.Context, out chan

如果采用 done := make(chan struct{})，也应规定只有一个拥有者负责 close(done)，或用 sync.Once 保护关闭动作。取消信号和数据 channel 分开后，数据 channel 仍可由协调者按完整生命周期关闭。

上线前按五项清单复查关闭设计

测试时重点覆盖：接收方提前退出、缓冲区满、多个生产者同时结束、重复取消和 nil channel。若关闭责任无法画成一条清晰的所有权线，说明接口还需要拆分，先修设计再补 recover。

Go channel 关闭常见问题

接收方能不能关闭 channel？

除非接收方同时明确拥有“以后不会再有任何发送者”的证明，否则不应关闭。通常由发送方协调者关闭，接收方只负责消费和取消。

关闭前能否用 select 判断 channel 是否已关闭？

不能得到可靠的“可安全发送”结论。判断之后仍可能被另一个 goroutine 关闭，应该改成所有权协议或取消协议。

用 recover 捕获 send on closed channel 可以吗？

只能作为边界层的异常记录，不能替代同步。捕获后还要面对丢数据、重复处理和 goroutine 生命周期问题，生产代码应先消除错误关闭路径。