向已关闭的 channel 写入会引发 panic，无法通过 recover 挽救；必须用 defer+recover 在 goroutine 中捕获，而非直接用 recover() 包裹 ch。
向已关闭 channel 写入不能靠 recover 挽救
直接用 recover() 包裹 ch 来“优雅处理”已关闭 channel 的写入，是反模式。它不会让逻辑变健壮，只会把 panic 变成静默失败或二次 panic。
根本原因有三：
-
panic: send on closed channel是 Go 运行时强制触发的致命错误，不是可预期的业务异常； -
recover()虽能捕获，但无法修复通道已关闭这一事实——后续仍可能因状态不一致再次 panic（比如继续往同一ch写、或误判ok状态）； - 这种写法绕过静态检查（
go vet、staticcheck无法告警），掩盖了所有权混乱或竞态关闭等真实缺陷。
close() 多次调用也会 panic，且 recover 无效
close(ch) 对已关闭 channel 再调用一次，会触发 panic: close of closed channel。这个 panic 无法被 recover() 捕获——除非你在 defer 中提前注册并恰好在 panic 发生前执行到该 defer，但这属于侥幸，且违背设计意图。
真正安全的做法是确保关闭动作只发生一次：
立即学习“go语言免费学习笔记（深入）”；
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 用
sync.Once封装关闭逻辑：once.Do(func() { close(ch) })； - 或由单一 goroutine 全权负责：写入完成时
defer close(ch)，外部通过done通道通知提前退出； - 避免多个 goroutine 都持有
ch的写权限，更不要各自判断“该我关了”。
select 中禁用写入分支的标准写法是置为 nil
当多个 goroutine 并发写入，且需响应外部信号（如超时、取消）停止写入时，不能靠 recover 去兜底，而应主动控制通道参与 select 的时机。
标准惯用法是将待禁用的发送通道设为 nil：
var sendCh chan<- int = ch
for {
select {
case sendCh <- data:
// 正常发送
case <-done:
sendCh = nil // 禁用该分支，后续此 case 永远阻塞
}
}
注意点：
-
nil通道在select中永不就绪，相当于逻辑上“移除”该分支； - 必须是变量赋值为
nil，不能直接写case nil <- data:（语法错误）； - 该技巧只适用于
select场景，不解决裸写ch <- x的风险——后者必须从设计上杜绝。
recover 只对同 goroutine 有效，且必须在 defer 中
如果你坚持要在某处用 recover()，务必确认三点：
- 它必须出现在
defer func() { ... recover() ... }()里，写在普通代码流中恒返回nil； - 它只能捕获当前 goroutine 的 panic，子 goroutine 的
ch <- xpanic 完全收不到； - recover 后别复用原 channel 或依赖其状态，例如：不能接着调用
len(ch)或再起一个for range ch——此时ch已处于不可预测状态。
最易忽略的是：recover 不等于“恢复”，它只是让程序不崩溃，但 channel 关闭的事实没变，数据一致性已丢失。真要容错，得靠明确的所有权 + 同步控制，而不是事后补漏。
