Go 关闭 channel 后继续发送为什么直接 panic

Go 关闭 channel 后继续发送为什么直接 panic？因为 close(ch) 表示这个 channel 不会再有新的值；它不是“暂时停用接收”，也不会等待已经启动的发送方。任何 goroutine 之后执行 ch ，都可能触发 panic: send on closed channel，即使 channel 还有缓冲空间。

可靠的规则只有一条：由能够证明“所有发送都结束”的发送方负责关闭 channel；接收方只消费，不替仍可能发送的 goroutine 关闭数据 channel。

panic 发生在发送点，不在 close 调用点

Go 规范把三种行为分得很清楚：关闭双向或发送方向的 channel 会记录“不会再发送”；向已关闭 channel 发送会 panic；从已经关闭且读空的 channel 接收则立即得到元素类型的零值，并可通过第二个返回值 ok == false 判断结束。

package main

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

缓冲只改变发送何时阻塞，不改变关闭后的状态。下面这张结构图把“发送者、关闭者和接收者”的边界放在一起：问题不在接收动作本身，而在关闭之后仍保留着一条可执行的发送路径。

把关闭权收回到发送方

最容易维护的模型是“生产者创建并关闭，消费者只接收”。生产者把所有发送放在一个 goroutine 中，并用 defer close(out) 覆盖自然结束和提前返回；消费者用 range 等待关闭信号。

func producer(values []int) 

是重要的接口边界：调用方拿到的值不能发送，也不能关闭。若调用方需要中途停止，应增加取消信号，而不是把这个输出 channel 强行关闭。

多个发送方和取消场景怎么安排

多个 goroutine 共用一个输出 channel 时，任何一个 worker 都不能凭感觉调用 close(out)。做法是用 sync.WaitGroup 等待全部 worker 退出，再让唯一的 closer 关闭输出；worker 的每次发送同时监听取消信号。

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

这里的关键不是 sync.Once，而是发送与关闭之间的先后关系。sync.Once 可以防止重复关闭，却不能证明另一个 worker 已经停止发送；“先判断 channel 是否关闭再发送”也不是无竞态方案，因为判断和发送之间仍可能被其他 goroutine 关闭。

发布前的 channel 并发检查清单

• 是否明确记录了每条 channel 的创建者、发送者和关闭者？
• 关闭前是否能证明所有发送 goroutine 都已返回，而不是只完成了其中一个？
• 接收方是否使用 range 或 v, ok := 处理结束，而不是主动关闭输入？
• 取消、超时和数据结束是否使用独立的 context.Context 或 done channel 表达？

如果 panic 只在压力下出现，优先沿着“谁最后调用 close、谁还可能执行 send”回溯 goroutine 生命周期。把关闭动作集中到一个可见位置，再用等待机制连接所有发送方，通常比在发送点包一层 recover 更容易定位，也不会把数据丢失伪装成正常退出。

常见问题

有缓冲 channel 为什么仍然会 panic？

缓冲只提供暂存空间。channel 一旦关闭，发送操作的语义立即改变，后续发送不再进入缓冲区，而是直接 panic。

发送前能不能先判断 channel 是否已关闭？

没有可靠的“检查后发送”组合。关闭状态可能在检查返回后立刻变化，应改为协调关闭者和发送者的生命周期。

接收方什么时候可以关闭 channel？

只有接收方同时能证明自己是唯一发送者，且没有其他发送路径时才有这个权限。一般并发管道中，接收方不应关闭仍可能被发送的 channel。