Go语言中recover与channel关闭的真相：别指望用它来收拾残局
先说结论：recover 并不能帮你关闭通道。这不仅仅是一个技术细节，更是一个设计原则问题。许多开发者会想当然地在 defer + recover 里顺手把通道关闭，认为这样就能“优雅”地处理 panic 后的资源清理。然而现实往往比想象中更复杂，处理不当反而会引发一连串连锁 panic。
recover 究竟能否直接关闭通道？
不能。recover 本质上只是一个“panic 捕获器”，它不持有 goroutine 的上下文，也不管理通道的状态，更不会替你判断通道是否应该关闭。试图在 recover 里“顺手”关闭通道，往往是因为忽略了 panic 发生时，当前 goroutine 的执行状态已经变得不可控。通道可能正被其他 goroutine 锁定，或者正处于收发中途，贸然关闭只会让局面更加糟糕。
panic 后通道状态已不可信，必须提前设计关闭路径
真正可控的通道关闭，只能发生在两个时机：要么在 panic 发生之前，要么你已经明确知道没有其他 goroutine 正在使用它。常见的错误写法是：在 defer + recover 里写一句 close(ch)，却忽略了 ch 可能已经被关闭过一次（重复关闭会引发 panic），或者还有别的 goroutine 正在往里面发送数据（向已关闭通道发送同样会触发 panic）。
这里有几个关键点需要牢记：
- 通道只能被关闭一次，重复关闭会引发 panic
- 向已关闭的通道发送数据会 panic，但接收数据是安全的（直到缓冲取完，后续返回零值）
- Go 语言本身没有提供“原子性地关闭通道并通知所有读者”的内置机制，需要借助
sync.Once或额外的 done channel 来协调
推荐做法：用 done channel + select 控制生命周期，recover 仅作兜底日志
把通道关闭的逻辑从错误处理中剥离出来，交给主控流程去决定。比如你启动一个 worker goroutine，可以同时传入一个 done 通道，配合 select 监听退出信号：
func worker(in <-chan int, out chan<- string, done <-chan struct{}) {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panicked: %v", r)
// 不在这里 close(out)！out 关闭由外部统一协调
}
}()
for {
select {
case v, ok := <-in:
if !ok {
return
}
out <- fmt.Sprintf("processed: %d", v)
case <-done:
return
}
}
}
主流程需要终止时，先关闭 in（通知 worker 不再接收新任务），然后等待 worker 退出，最后才安全地执行 close(out)。这样一来，关闭通道的职责就非常清晰，与 panic 处理完全解耦。
如果真要 recover 后关通道，唯一安全场景是单生产者 + 无并发读写
当然，有一种极其狭窄的场景可以这样做：你能够 100% 确认，该通道只被当前 goroutine 使用，没有其他 goroutine 在阻塞收发，并且你捕获的 panic 与通道操作无关（比如是计算逻辑出了问题）。此时，你可以考虑在 recover 块中关闭通道：
ch := make(chan int, 1)
defer func() {
if r := recover(); r != nil {
// 确认 ch 尚未关闭，且无其他 goroutine 涉及它
if _, ok := <-ch; !ok { // 尝试非阻塞读，判断是否已关闭
close(ch) // 仅在此类严格受控场景下可行
}
}
}()
但说实话，这种模式非常脆弱，很难验证，生产环境中应优先选择 context 或 done channel 来驱动关闭，而不是依赖 recover 的时机。
最后想强调一点：recover 不是资源清理钩子，它只是 panic 的逃生舱门。真正的资源管理（包括通道关闭）必须依靠结构化控制流，而不是靠“出事后再补救”。这个原则，理解得越早，踩的坑就越少。
