recover只能捕获当前goroutine中panic，且必须在defer函数内、panic发生后、函数返回前调用；反射调用引发的panic需在同层函数用defer+recover包裹，跨goroutine或外层封装均无效。
recover在反射调用中根本不起作用？
直接上结论：recover 只能捕获当前 goroutine 中 panic，且必须在 defer 函数内、panic 发生之后、函数返回之前调用。而反射执行（如 reflect.Value.Call）内部触发的 panic，默认会向上冒泡到调用栈外——如果你没在反射调用的**同一层函数**里用 defer + recover 包裹，就完全捕获不到。
必须在反射调用的外层函数加 defer recover
常见错误是把 recover 放在更外层或单独封装的“错误处理函数”里，结果毫无效果。正确做法是：所有可能通过 reflect.Value.Call、reflect.Value.MethodByName 等触发 panic 的地方，必须紧挨着写 defer：
func safeCall(v reflect.Value, args []reflect.Value) (results []reflect.Value, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic during reflection call: %v", r)
}
}()
return v.Call(args), nil
}
-
v.Call(args)一旦内部 panic（比如方法里空指针解引用、索引越界），recover()就能截住 - 不能把
defer写在调用safeCall的函数里——那已经晚了，panic 已经离开safeCall栈帧 - 如果
v是未导出字段或不可调用值，Call本身会 panic，这也被覆盖
注意 recover 后的返回值和类型安全
反射调用失败后，你拿到的是 err != nil，但 results 是空切片。这时候别直接取 results[0] 或强转——容易 panic 二次崩溃：
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 检查
err是否为nil，再处理results - 如果原函数返回多个值，
results长度不固定；用len(results) > 0判空，而非假设 -
recover()返回的是interface{}，不是error；别直接当error赋值，要显式转成字符串或包装 - 某些 panic（如
runtime.errorString）可转fmt.Sprint(r)，但自定义 panic 类型建议统一实现error接口
goroutine 和 recover 的边界很窄
如果反射调用发生在新 goroutine 里（比如 go fn.Call(args)），那这个 recover 完全无效——每个 goroutine 的 panic 必须由它自己的 defer 捕获：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in goroutine: %v", r)
}
}()
fn.Call(args)
}()
- 主 goroutine 的
defer对子 goroutine 的 panic 无感知 - 跨 goroutine 的 panic 无法透传，也不能靠 channel 带回 panic 值（
recover不是返回值） - 真要统一处理，得用
recover捕获后发到 channel 或写日志，别指望“恢复执行流”
反射本身不增加 panic 风险，但它抹平了编译期检查，让运行时错误更隐蔽；recover 不是兜底银弹，只是给你一次记录、降级或返回默认值的机会。最易忽略的点是：defer 的位置必须比反射调用深一层，且不能跨 goroutine —— 错一格，就彻底失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
