recover 只在 defer 函数中且于 panic 的 goroutine 内执行时才有效；闭包需作为 defer 参数（不加括号）延迟执行，内部调用 recover 并处理返回值，否则返回 nil。
为什么直接在闭包里调用 recover 总是返回 nil
因为 recover 只有在 defer 函数中、且该函数正在 panic 的 goroutine 中执行时才有效。闭包本身不是 defer 点，如果只是把带 recover 的闭包赋值给变量或传参，它不会自动绑定到 panic 恢复链上——必须显式用 defer 包裹它。
正确写法：用 defer 执行闭包，并在闭包内调用 recover
常见错误是写成 defer func() { recover() }()，这会立即执行闭包（此时还没 panic），recover 必然返回 nil。正确方式是让闭包延迟执行，且内部能捕获当前 panic：
- 闭包必须作为
defer的参数，不加括号：defer func() { ... }()是错的；defer func() { ... }才对 - 闭包内要先调用
recover()，再处理返回值，不能漏掉赋值 - 如果需要访问外部变量（如日志句柄），直接引用即可，Go 闭包会自动捕获
func risky() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
}
}()
panic("something went wrong")
}
闭包中恢复后如何区分 panic 类型和继续执行
recover() 返回的是 interface{}，具体类型取决于 panic 的参数。硬类型断言容易 panic，建议用 fmt.Sprintf("%v", r) 做通用字符串化，或按需判断：
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 如果
panic(nil)，recover()返回nil（注意不是interface{}的零值） - 如果
panic("msg")，返回string类型，可用r.(string)安全断言（配合ok判断） - 如果
panic(errors.New("x"))，返回error接口，可转成具体 error 处理 - 恢复后函数不会“回到 panic 那行”，而是从
defer闭包结束后继续向下执行（即 panic 后的代码不会运行）
嵌套闭包或多个 defer 时的恢复行为
每个 defer 都独立执行，但 recover 只能生效一次：第一次调用成功后，后续所有 recover() 都返回 nil。这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 不要在多个 defer 闭包里都写
recover()，只有第一个能捕获 - 如果外层函数已 recover，内层 goroutine 的 panic 不会被影响——
recover仅作用于当前 goroutine - 闭包捕获到 panic 后，无法“重新抛出”，只能记录或转换为其他错误返回；若需类似
throw行为，得手动panic(r)
最易被忽略的是：闭包里没做任何事就 return，或者把 recover() 放在条件分支里却没覆盖所有路径——结果就是 panic 依然向上冒泡。
