Go 并发原语 channel 关闭后发送为何 panic

Go 中对已经关闭的 channel 执行发送，运行时会直接触发 panic: send on closed channel。原因不是 channel 没有容量，而是 close(ch) 已经对所有发送者做出了承诺：后续不会再有新值进入这个通道。接收端仍可以读完关闭前已经发送的值，但发送端不能再写入。

修复这类问题的关键是把关闭责任交给“知道所有发送都结束”的一方。不要让接收者为了表示“我不需要了”直接关闭一个仍可能被多个生产者写入的 channel；取消接收通常应通过独立的退出信号或 context.Context 协调。

先看清 close 后的三种行为

channel 的状态变化可以概括为：关闭前可以按容量发送和接收；关闭后不能发送，但接收仍会继续取出关闭前已经放入的值；缓冲区清空后，接收操作返回元素类型的零值，并且第二个布尔值为 false。

为什么发送操作一定会 panic

看一个最小例子：

package main

func main() {
    ch := make(chan int, 1)
    ch 

这里的缓冲区大小只影响“关闭前什么时候会阻塞”，不改变关闭后的规则。即使缓冲区仍有空间，ch 也不会成功。Go 语言规范明确规定，对已关闭 channel 的发送会造成运行时 panic；对已关闭 channel 再次调用 close 也会 panic。

这也是为什么“发送前先检查 channel 是否关闭”不是可靠修复。Go 没有一个通用的、无竞态的 isClosed(ch) 检查：检查完成后，另一个 goroutine 仍可能马上关闭它。真正需要修复的是关闭责任和并发协议，而不是给发送语句套一个猜测状态的判断。

关闭责任应该放在哪里

一个简单规则是：谁创建并组织发送，谁负责在所有发送结束后关闭；接收者只负责读取。单生产者可以直接在发送循环结束后关闭：

func produce(out chan

调用方可以用 range 读取到关闭信号，避免把零值误当成真实数据：

func consume(in 

多个生产者要等全部发送完成

多生产者场景中，任意一个生产者都不能仅凭“我发完了”就关闭共享 channel。可以让协调者等待所有生产者退出，再执行唯一一次关闭：

package main

import "sync"

func startWorkers(out chan

这段代码的约束很重要：生产者拿到的是 chan，它只能发送；关闭动作集中在协调者手里。类型方向不能替代完整的生命周期设计，但能减少误把接收端或任意调用方当成关闭者的机会。

接收者提前退出时不要抢着 close

如果消费者只需要前几个值就返回，生产者可能还在发送。此时消费者直接关闭 out 会把仍在运行的生产者变成“向已关闭 channel 发送”，最终触发 panic，或者让生产者永久阻塞。

更稳妥的做法是增加取消通道，让生产者在发送时同时监听退出信号：

func sendWithCancel(done 

对于更复杂的调用链，可以使用 context.Context 传递取消原因。无论采用哪种方式，取消信号和数据 channel 的关闭是两件事：前者通知发送方停止工作，后者声明不会再有新值，不能混为一个动作。

排查 panic 时按这张清单看

1. 搜索所有 close(ch)，确认是否存在多个关闭点。
2. 找出所有 ch ，判断发送者是否可能在关闭后继续运行。
3. 确认关闭动作是否等待了所有生产者，而不是只等待一个 goroutine。
4. 如果接收者会提前返回，检查是否有独立取消信号让生产者退出。
5. 用 value, ok := 或 range ch 判断接收结束，不用发送端反推接收者状态。

一句话记忆：发送者负责关闭，且必须在所有发送完成后关闭；接收者只接收，提前退出时通过取消协议通知生产者。

常见延伸问题

关闭 channel 会丢掉缓冲区里的值吗？

不会。关闭只禁止新的发送，接收者仍可读取关闭前已经进入缓冲区的值。

能不能用 recover 兜住 send on closed channel？

可以捕获当前 goroutine 的 panic，但这通常只是隐藏了错误的生命周期协议，不能让这次发送成功，也不能保证其他发送者安全。应优先修复关闭责任。

nil channel 和 closed channel 一样吗？

不一样。向 nil channel 发送会永久阻塞；向 closed channel 发送会 panic；关闭 nil channel 本身也会 panic。

参考文档：https://go.dev/ref/spec#Channel_types、https://go.dev/ref/spec#Send_statements、https://go.dev/ref/spec#Close