Go 通道关闭通道后发送触发 panic 怎么办

向已经关闭的 Go 通道发送数据会触发 panic，缓冲通道也不例外。修复重点不是先判断通道是否关闭，而是保证关闭发生时所有发送者都已退出，并且以后不会再出现发送。单发送者通常自己关闭输出；多发送者共享输出时，应由协调者等待全部发送者结束，再统一关闭。

这不是必须升级 Go 才能解决的问题。需要改变的是组件的关闭协议：接收方想提前退出，用取消信号通知上游，不要直接关闭仍有人发送的数据通道。下面代码为未运行的原创示例，不包含虚构的现场日志或测试结果。

官方地址：https://go.dev/ref/spec#Send_statements

无需升级版本，先改关闭协议

close 表达“这个通道以后不会再有发送”，并不是一个对发送者发出停止请求的命令。调用 close 不会等待发送者完成，也不会把后续发送变成可忽略的失败值。关闭后继续发送、重复关闭，都有 panic 风险。

排查时应从报错对应的发送语句入手，找出这个通道的所有别名、发送点和关闭点。如果某个接收者在退出分支里关了通道，而发送者只靠循环条件“稍后会停”，两者之间就没有可靠的同步保证。不要用增加 sleep 的方式填补这个空隙。

关闭表示不再发送，不是要求上游停工

先划分三项职责：发送者生产数据，接收者消费数据，协调者管理共享输出的结束。多个发送者不能各自在退出时关闭同一个输出，否则最先结束的人会切断其他发送者。接收者也不能因为自己不读了，就替所有上游宣告发送结束。

本文的组件使用输出通道 out 传数据，使用 ctx.Done 接收取消通知，使用 finished 通知调用方整个组件已完成收尾。三个对象含义不同，不能互相替代。接收者若提前放弃，应调用它持有的 cancel，之后可以等待 finished；不能关闭 ctx.Done，也不能关闭 out。

多发送者只让协调者关闭输出

下面的完整程序让两组有限输入共享输出。WaitGroup 在启动发送者前注册计数；每个发送者在退出时调用 Done；唯一协调者等待后关闭输出。调用方只能拿到只读通道，接口上减少了误关输出的机会。

package main

import (
    "context"
    "fmt"
    "sync"
)

// startSources 只公开接收端；输入切片在任务结束前不可被并发修改。
func startSources(ctx context.Context, sources [][]int) (

示例预期输出四个输入值，每个值一次，两组之间的交错次序不固定；这里没有展示实际执行结果。两组输入都为空时，发送者会直接结束，协调者仍能完成关闭；sources 没有任何组时，计数从一开始就是零，协调者也会关闭输出。

如果接收者只要部分结果，应在决定放弃后显式调用 cancel，再等待 finished。只写 defer cancel 却先等待 finished，可能让取消延迟到等待结束之后：如果上游正卡在发送，就会互相等待。使用者要把“通知取消”和“等待收尾”的关系写清楚。

取消不是一个保证零额外发送的事务屏障。当接收分支和发送分支同时就绪时，select 不承诺优先选取消；前面的 ctx.Err 检查也不能消除检查之后的时序变化。本例的关闭安全来自 WaitGroup 和唯一关闭者，不依赖“取消后绝不再发送一次”这种过强假设。

旧代码迁移时移除三个伪保护

先读 ok，再发送

二值接收的 ok 用于解释一次接收是否来自已经关闭且耗尽的通道，不是无副作用的可发送状态查询。为了探测状态而接收，可能吃掉真实数据；即便观察到未结束，也不代表下一次发送时仍然未关闭。len 或 cap 同样不能证明未来发送安全。

把发送放进带 default 的 select

default 用于没有通信可以进行时避免阻塞，不是 panic 捕获器。关闭通道上的发送不会被 default 自动屏蔽。即便另一个取消分支已经就绪，也不能把 select 当作对关闭与发送的互斥保护。

给 close 套 sync.Once

Once 可以限制所包装的关闭函数只执行一次，但不能证明其他协程不再发送。如果接收者过早触发一次关闭，发送者仍可能在之后 panic。要解决的不是仅仅“谁能第二次关”，而是“第一次关时，还有谁能发送”。

用退出条件检查修复是否完整

迁移时列出所有可能发送的协程，确认它们都被同一个等待机制覆盖，并且没有在 Wait 完成后才新增发送者。若发送者内部还启动了异步发送任务，这些任务也必须进入生命周期约定，不能在外层 Done 后继续向 out 发送。

建议在项目测试中覆盖上述情况，增加取消发生于发送等待期间的用例，并检查所有参与者能否退出。并发测试和竞态检测可以补充发现问题，但不代替关闭权的设计说明。本文没有为了配图运行程序，也不把这些预期称为已经通过的测试。

扩大缓冲区能解决吗？

不能。缓冲只影响关闭前的发送等待，通道关闭后发送仍会 panic；把容量调大可能只是改变故障出现的时机。缓冲中的既有数据可以在关闭后继续接收，耗尽之后才返回零值和 false。

recover 能让发送自动重试吗？

不能把它当作正常协议。recover 必须在发生 panic 的同一协程的适当延迟函数中起作用，捕获后也不会从出错发送语句继续执行或恢复通道状态。它不能证明业务数据已送达，通用吞错还会掩盖生命周期缺陷。

通道一定要关闭吗？

不必为“释放通道内存”而关闭每一个通道。关闭的意义是协议通知；内存回收取决于引用关系。但如果接收者通过 range 等待发送结束，就必须有清楚的关闭安排，否则它可能一直等待。

修复原则可以压缩成一句话：停止发送靠取消与协作，宣告发送结束靠唯一关闭者以及完整的退出证明。两者分开后，才不需要猜测通道当前状态。

官方资料

发送、接收、select 与关闭规则：https://go.dev/ref/spec

等待发送者：https://pkg.go.dev/sync#WaitGroup

流水线与取消：https://go.dev/blog/pipelines