Go 程序出现 panic: send on closed channel 报错，直接原因是代码向一个已经执行过 close 操作的 channel 发送了数据。排查时优先查看 panic 堆栈定位发送代码行，并检查通道关闭逻辑是否由发送方错误触发。

快速处理思路

此类报错没有命令行修复方案，需通过代码审查和堆栈分析解决。

1. 复制 panic 日志中的 goroutine 堆栈信息。
2. 在 IDE 中跳转到堆栈指出的发送代码行。
3. 向上追溯该 channel 变量的 close 调用位置。

为什么会这样

Go 语言规范明确规定，向已关闭的通道发送数据会触发 panic，而接收数据只会返回零值。

channel 关闭后内部状态标记为 closed，发送操作检查到此状态会立即中断程序。这通常发生在生产者 - 消费者模型中，消费者提前退出或多次调用 close，而生产者仍在尝试写入。

分步处理

按照以下顺序修改代码逻辑，避免发送关闭的通道。

1. 定位发送点

查看日志中 panic 后的堆栈跟踪（stack trace），找到类似 main.go:45 的行号。该行代码通常形如 ch <- data。

2. 确认关闭方

搜索项目中对该 channel 变量调用 close(ch) 的位置。根据 Go 并发最佳实践，通常应由接收方（receiver）负责关闭通道，或者由创建通道的协程在确认不再发送后关闭。

3. 增加同步机制

如果必须由发送方关闭，确保所有发送协程完成后再关闭。使用 sync.WaitGroup 等待所有发送者结束，或在主协程中统一关闭。

4. 使用 Context 控制

对于复杂生命周期，使用 context.Context 替代 channel 关闭信号。发送前检查 ctx.Done()，避免在任务取消后继续发送。

怎么验证是否生效

修改代码后，通过本地复现和竞态检测确认问题修复。

• 运行 go test -race ./... 检查是否存在数据竞态导致的关闭时机不确定。
• 在测试用例中模拟高并发发送和接收，观察是否再次出现 panic。
• 检查日志，确认程序正常退出而非异常中断。

常见坑

• 多次关闭：对同一个 channel 调用两次 close 也会 panic，需确保 close 只执行一次。
• 发送方关闭：多个发送者共享一个 channel 时，任意一个发送者关闭通道会导致其他发送者 panic。
• 忽略 recover：虽然可以用 recover 捕获 panic，但这会掩盖逻辑错误，不建议作为常规处理手段。

常见问题

发送关闭的 channel 一定能 recover 吗？

可以捕获但不应依赖。使用 defer recover() 能阻止程序崩溃，但无法修复通道状态，后续发送仍会失败。

range 遍历 channel 会自动关闭吗？

不会。range 会在 channel 关闭且缓冲区为空时退出，但关闭操作必须由代码显式调用 close。

为什么接收关闭的 channel 不会 panic？

Go 语言设计如此。接收关闭的 channel 会立即返回零值和 false，允许程序优雅处理结束状态。

参考来源

• The Go Programming Language Specification, Send statements, https://go.dev/ref/spec#Send_statements
• Effective Go, Concurrency, https://go.dev/doc/effective_go#concurrency
• Go Blog, Pipelines, https://go.dev/blog/pipelines