recover无法捕获动态调用（如reflect.Call或闭包）中的panic，除非在同一goroutine、同一调用栈深度且已注册defer的前提下显式包裹；goroutine分离时recover完全失效。
recover 不能捕获动态函数调用（如 reflect.Value.Call 或闭包执行）中抛出的 panic，除非你在**同一 goroutine、同一调用栈深度、且 defer 已注册的前提下**显式包裹该调用——这是最常被忽略的前提。
为什么 reflect.Call 或回调函数里的 panic 捕不到
动态调用本身不改变 goroutine 上下文，但容易踩两个坑：
一是 defer 注册位置不对（比如在调用方注册，但 panic 发生在被反射调用的函数内部，而该函数没自己的 defer）；二是 recover() 被包在另一层普通函数里，违反“必须在 defer 函数中直接调用”规则。
常见错误现象：
• recover() 返回 nil，日志里看不到 panic 信息
• panic 仍导致整个程序退出，或仅打印默认堆栈后终止
• 在 HTTP handler 中对用户传入的 http.HandlerFunc 做反射调用，却没在 handler 内部注册 defer
- 动态调用前必须确保当前函数已执行过
defer func() { ... recover() ... }()，不能依赖外层函数的 defer - 若用
reflect.Value.Call执行函数，panic 会发生在反射目标函数栈帧内，只有它自己或其直接 caller 的 defer 才可能捕获 - 不要写
defer handlePanic()然后在handlePanic里调recover()—— 这属于“间接调用”，recover()失效 - HTTP 中间件若要捕获 handler 的 panic，必须在中间件函数体开头就注册 defer，而不是在包装后的 handler 里注册
正确封装动态调用 + recover 的模式
核心是：把 panic 风险操作包进一个有自己 defer 的作用域。不是“外面包一层”，而是“里面包一层”。
立即学习“go语言免费学习笔记（深入）”；
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
例如处理用户传入的回调：
func runCallback(cb func()) (err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("callback panic: %v", r)
}
}()
cb()
return
}再比如用 reflect 安全调用：
func safeReflectCall(fn reflect.Value, args []reflect.Value) ([]reflect.Value, error) {
defer func() {
if r := recover(); r != nil {
// 注意：debug.Stack() 必须在这里立即调，不能等 defer 外再取
stack := string(debug.Stack())
log.Printf("reflect call panic: %v\n%s", r, stack)
}
}()
return fn.Call(args), nil
}- 每个可能 panic 的动态入口点，都应配一个独立的 defer+recover 块
- 不要复用同一个 defer 函数处理多个不同调用点，否则无法区分 panic 来源
-
debug.Stack()必须在recover()后立刻执行，否则后续 defer 可能污染栈帧 - 返回
error而非继续 panic，避免调用方误以为操作成功
goroutine 分离场景下 recover 完全失效
如果你在新 goroutine 里做动态调用（比如 go cb() 或 go fn.Call(args)），那么主 goroutine 的 recover() 对它完全无效——这是根本性限制，不是写法问题。
常见错误现象：
• 主流程无报错，但子 goroutine panic 后静默退出，资源未释放
• 日志里找不到任何 panic 记录，怀疑代码没执行
- 子 goroutine 必须自己注册
defer func() { recover() }()，且必须在go语句块内部完成 - 不能指望父 goroutine “代为捕获”，它们的 panic 生命周期完全隔离
- 若需统一收集子 goroutine panic，得靠 channel + 错误传递，例如
errCh <- fmt.Errorf("panic: %v", r) - HTTP handler 中启动的 goroutine，尤其要注意连接、超时、context.Done() 的清理，recover 只解决崩溃，不解决泄漏
真正难的不是写对 recover，而是判断 panic 是否真的该被 recover——动态调用往往意味着控制权移交给了不可信代码，此时 recover 只是兜底，状态一致性得靠设计保证，比如避免共享可变状态、用只读参数、每次调用前 clone 数据。
