不能。recover无法捕获向已关闭channel发送数据引发的panic，因其是同步runtime panic，必须由发送方在发送前通过状态检查或select+default规避，而非依赖defer+recover捕获。
recover 能不能捕获向已关闭 channel 发送数据的 panic
不能。recover 只能在 defer 函数中、且当前 goroutine 正处于 panic 状态时生效；而向已关闭的 chan<T> 发送数据会立即触发 runtime panic（send on closed channel），这个 panic 不在 defer 链中，recover 捕获不到。
为什么 defer + recover 在发送前加保护无效
常见错误写法是把 defer 和 recover 放在发送逻辑外层函数里，比如：
func sendSafe(ch chan int, v int) {
defer func() {
if r := recover(); r != nil {
log.Println("recovered:", r)
}
}()
ch <- v // panic 在这里发生，但 defer 已注册，为何还崩溃？
}问题在于：panic 发生时，当前 goroutine 的栈开始回退，defer 确实会执行，但此时 panic 未被任何 recover 拦截——因为 recover() 必须在同一个 goroutine 中、且在 panic 传播路径上尚未退出当前函数时调用才有效。上面代码中 ch <- v 是顶层语句，panic 后直接终止函数，defer 虽运行，但 recover() 已错过拦截时机。
- 只有在 panic 发生后、函数返回前，且
recover()处于正在执行的 defer 函数内，才能生效 - 向关闭 channel 发送是同步 panic，不经过调度器，无法“绕开”或“延迟”处理
- Go 运行时禁止对已关闭 channel 执行发送操作，这是确定性检查，不是可忽略的错误
真正安全的 channel 发送保护方案
不要依赖 recover，改用显式状态控制和 select 配合 default：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Once或原子变量标记 channel 是否已关闭，发送前先读取状态 - 对不确定是否关闭的 channel，用
select+default实现非阻塞尝试发送（但注意：这仍会 panic，不能解决根本问题） - 正确做法是：由 channel 的**拥有者**负责生命周期管理，发送方只应在明确知道 channel 未关闭时才发送
- 更实用的模式是封装带关闭通知的 channel，例如用
struct { ch chan T; closed atomic.Bool }，发送方法内部做if !c.closed.Load() { c.ch <- v }
示例（推荐）：
type SafeChan[T any] struct {
ch chan T
closed atomic.Bool
}
<p>func (sc *SafeChan[T]) Send(v T) bool {
if sc.closed.Load() {
return false
}
select {
case sc.ch <- v:
return true
default:
return false
}
}</p><p>func (sc *SafeChan[T]) Close() {
if sc.closed.Swap(true) {
return
}
close(sc.ch)
}哪些场景下你其实不需要 recover
绝大多数生产代码中，向 channel 发送失败的根本原因不是“意外关闭”，而是设计缺陷：
- 多个 goroutine 并发关闭同一 channel → 应统一由创建者关闭，其他方只负责发送或接收
- 发送方不知道接收方已退出 → 应配合
context.Context或 done channel 做协同退出 - 试图用 channel 传递“错误信号”而非业务数据 → 换成返回 error 更清晰
真正需要防御的，是 channel 的**所有权边界是否清晰**；一旦边界模糊，加再多 recover 也掩盖不了竞态和逻辑漏洞。
