json.Unmarshal 解析失败不会 panic，而是返回 error，应通过检查 error 处理；recover 不适用于 JSON 解析异常，仅在调用不可控第三方库或 HTTP handler 防崩时谨慎使用。
在 Go 中，json.Unmarshal 解析失败时**不会 panic**，而是返回 error，因此通常不需要、也不应该用 recover 来捕获 JSON 解析异常。滥用 recover 不仅无法解决问题，还会掩盖真实错误、降低可读性与可维护性。
JSON 解析本身不触发 panic
Go 的标准库 encoding/json 设计为“显式错误处理”：所有解析失败（如格式错误、字段类型不匹配、结构体字段不可导出等）都通过返回 error 告知调用方，而非 panic。例如：
✅ 正确做法：检查 error
var user struct{ Name string }
err := json.Unmarshal([]byte(`{"Name": 123}`), &user) // 类型不匹配
if err != nil {
log.Printf("JSON 解析失败: %v", err) // 输出明确错误信息
return
}
什么情况下 recover 才可能“相关”？
极少数场景下，你可能在 JSON 解析前后主动 panic（比如自定义 UnmarshalJSON 方法中手动 panic），或在 defer/recover 链中误包了 JSON 操作。但这是非标准用法，应避免。真正需要 recover 的通常是：
• 调用第三方库时不确定其是否 panic
• 处理用户输入前做防御性兜底（非常规）
• HTTP handler 中防止整个 goroutine 崩溃（但应优先用 error 返回）
推荐的健壮处理方式
• 使用 json.RawMessage 延迟解析不确定结构的字段
• 对关键字段做类型断言 + 错误检查（如解析为 interface{} 后判断类型）
• 封装通用解析函数，统一日志、指标和 fallback 行为
• 在 HTTP API 中，将解析 error 转为 400 Bad Request 并返回清晰提示
如果坚持要用 recover（不推荐）
仅当你的代码中存在其他不可控 panic 且 JSON 解析恰在同一 goroutine 中时，可加一层 defer/recover，但必须：
• recover 后判断 panic 值是否为预期类型（如 fmt.Errorf）
• 记录 panic 堆栈用于排查
• 明确区分“JSON error”和“真实 panic”，不要把 error 当 panic 处理
