recover不能恢复panic后的执行流，仅能阻止崩溃并将控制权交还给defer所在函数的上层调用者；必须在defer中调用才有效，且只对当前goroutine生效，捕获后函数立即return，不执行后续代码。
recover 不能“恢复” panic 后的执行流，只能阻止程序崩溃并让控制权回到 defer 所在函数的上层调用者——这是最常被误解的一点。
recover 必须写在 defer 函数里才有效
直接调用 recover() 永远返回 nil，因为它只在 panic 正在传播、且当前 goroutine 尚未退出时起作用。唯一可靠的方式是把它包在 defer 中：
错误写法：func bad() { recover(); panic("boom") }
正确写法：func good() { defer func() { if r := recover(); r != nil { fmt.Println("捕获到 panic:", r) } }(); panic("boom") }
原因在于：defer 在函数 return 前执行，此时 panic 还没终止当前栈帧，recover 才有机会介入。
recover 只对当前 goroutine 的 panic 生效
你无法在一个 goroutine 里用 recover 捕获另一个 goroutine 抛出的 panic。常见陷阱包括：
- 在
go func() { panic("x") }()外层 defer 中调用recover—— 无效 - 想用全局 defer 捕获所有子 goroutine 错误，必须每个 goroutine 内部单独加
defer+recover - HTTP handler 中启动 goroutine 处理请求，若不加内部 recover，panic 会导致整个进程退出（取决于运行时配置）
recover 后函数立即 return，后续代码不执行
即使捕获成功，panic 发生点之后的语句也不会运行。例如：
func example() { defer func() { recover() }(); panic("stop"); fmt.Println("never printed") }
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
这行 fmt.Println("never printed") 永远不会执行。这不是“异常处理后继续跑”，而是“中断后交还控制权”。
副作用（如已写入文件、已发送 channel、已修改 map）无法回滚，也不能重试。需要降级逻辑，得靠显式 error 返回 + if 判断，而不是依赖 recover。
recover 捕获的是 panic 参数，类型是 interface{}
recover() 返回值就是 panic 传入的参数，可以是 string、error、自定义 struct 等。实际使用中建议统一转成 error 类型以便下游处理：
if r := recover(); r != nil { err, ok := r.(error); if !ok { err = fmt.Errorf("%v", r) } log.Error("panic caught", "err", err) }
注意：如果 panic 传的是 nil（比如 panic(nil)），recover() 也会返回 nil，需额外判断避免空指针。
真正难的不是写对 recover，而是在 panic 发生前就预判哪些地方可能崩、哪些 goroutine 需要独立兜底、哪些副作用必须手动补偿——这些没法靠语法糖解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
