recover无法直接处理解码器panic，仅能在同goroutine中defer注册且未被拦截时捕获runtime级panic；常见触发原因包括nil指针解码、并发写map及反射越界，需预检+error优先，recover仅作最后兜底。
recover 不能直接“处理解码器 panic”，它只能在 panic 正在传播、且调用栈满足特定条件时捕获并中止崩溃——对 json.Unmarshal、xml.Unmarshal 或第三方解码器（如 yaml.Unmarshal）触发的 panic，必须严格满足 defer + 同 goroutine + 未被其他 recover 拦截 这三个前提，否则返回 nil。
为什么解码器 panic 很难被 recover 捕获
常见解码器（如标准库 json）本身不会主动 panic；但以下情况会间接触发 runtime panic：
-
json.Unmarshal对 nil 指针解码（如var p *struct{}; json.Unmarshal(b, p)）→ 空指针 dereference → runtime panic - 并发写 map（如多个 goroutine 同时向同一个 map 写入，且该 map 在解码过程中被修改）→
fatal error: concurrent map writes - 第三方解码器内部使用了不安全操作或反射越界（如某些旧版
gopkg.in/yaml.v2在解析嵌套过深结构时栈溢出）
这些 panic 发生在底层 runtime 或解码器私有函数中，调用栈往往很深。而 recover 只能捕获「当前 goroutine 中、尚未退出的、最近一次未被拦截的 panic」——如果 panic 已经穿透到主函数外、或被上层 defer 先一步 recover 了，你这层就什么都拿不到。
必须用 defer 包裹 recover，且位置要紧贴解码调用
错误写法：recover() 单独写在函数开头、或放在解码之后、或放在 if 分支里：
func badDecode(b []byte) error {
recover() // 永远 nil：panic 还没发生
var v struct{ Name string }
json.Unmarshal(b, &v) // panic 在这里
return nil
}
正确写法：defer 必须注册在解码前，且匿名函数体中立即调用 recover()：
func goodDecode(b []byte) (err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("decode panic: %v", r)
}
}()
var v struct{ Name string }
json.Unmarshal(b, &v) // panic 若在此发生，会被上面 defer 捕获
return nil
}
关键点：
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 必须用命名返回值
err，否则 recover 后无法把错误带出去 - defer 必须在解码调用之前注册，否则 panic 发生时该 defer 还没入栈
- 不要在 defer 里做耗时操作（如日志写磁盘、网络请求），panic 时 goroutine 已处于异常状态，IO 可能卡死
recover 捕获后，程序不会“继续执行”解码后续代码
这是最容易误解的一点：recover 不是重试机制，它只让函数跳过 panic 后剩余语句，然后 return。例如：
func example(b []byte) string {
defer func() { recover() }()
var v struct{ Name string }
json.Unmarshal(b, &v)
return v.Name // panic 发生时这行根本不会执行
fmt.Println("never reached") // 这行也不会执行
}
所以实际使用中，你要：
- 把解码逻辑封装成独立函数，便于 defer 隔离作用域
- 避免在 defer 中依赖解码后的变量（它们可能未初始化）
- 若需 fallback 行为（如尝试 JSON 失败后试 YAML），必须靠 error 判断，而不是靠 recover 后继续跑另一段解码
真正健壮的解码防护，靠的是预检 + error，不是靠 recover
绝大多数解码失败场景（格式错误、字段缺失、类型不匹配）都走 error 返回路径，不是 panic。你应该优先处理这些：
func robustDecode(b []byte) error {
// 先检查基础合法性，避免触发 panic
if len(b) == 0 {
return errors.New("empty input")
}
if !json.Valid(b) { // 标准库提供，低成本预检
return errors.New("invalid JSON")
}
var v struct{ Name string }
if err := json.Unmarshal(b, &v); err != nil {
return fmt.Errorf("unmarshal failed: %w", err)
}
// 此处 v 已安全初始化，可放心使用
return nil
}
只有当你明确知道某段解码逻辑存在 runtime panic 风险（比如传入了不可信的反射目标、或使用了已知有 bug 的旧版解码器），才加一层 defer+recover 做兜底。把它当成「最后保险丝」，而不是常规错误处理通道。
真正容易被忽略的是：recover 捕获到的 panic 值类型不确定（可能是 string、error、自定义 struct），直接 fmt.Sprint(r) 可能 panic 二次 —— 安全做法是先用 fmt.Sprintf("%v", r) 或类型断言兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
