json.Unmarshal 返回的 error 是接口值，实际类型通常为 json.SyntaxError、json.UnmarshalTypeError 或 *json.InvalidUnmarshalError，需用 errors.As 进行类型断言以精准区分错误来源。
json.Unmarshal 返回的 error 是什么类型
json.Unmarshal 返回的 error 是一个接口值，实际类型通常是 *json.SyntaxError、*json.UnmarshalTypeError 或 *json.InvalidUnmarshalError。直接用 err.Error() 看到的是人类可读字符串，但无法精准区分错误来源——比如是 JSON 格式错了，还是字段类型不匹配，还是传了 nil 指针。
正确做法是用类型断言或 errors.As 提取具体错误类型：
var data map[string]interface{}
err := json.Unmarshal([]byte(`{"name": "alice", "age": "not-a-number"}`), &data)
if err != nil {
var syntaxErr *json.SyntaxError
var typeErr *json.UnmarshalTypeError
if errors.As(err, &syntaxErr) {
fmt.Printf("JSON 语法错误，位置：%d/n", syntaxErr.Offset)
} else if errors.As(err, &typeErr) {
fmt.Printf("字段 %q 类型不匹配，期望 %v，得到 %v/n",
typeErr.Field, typeErr.Type, typeErr.Value)
}
}
解析时字段缺失或为空值怎么避免 panic
Go 的 json 包默认对空 JSON 对象（{}）或缺失字段不做报错，而是将对应字段设为零值。但如果结构体字段是**非指针非零值类型**（如 int、string），就无法区分“字段没传”和“字段传了零值”。这在 API 请求校验中容易埋坑。
- 用指针字段（
*string、*int）可区分 nil（未提供）和零值（显式提供） - 加
omitempty标签只影响序列化，不影响反序列化行为 - 需要强校验时，应在
UnmarshalJSON方法里手动检查字段是否存在，或用第三方库如go-playground/validator
例如：
立即学习“go语言免费学习笔记（深入）”；
type User struct {
Name *string `json:"name"`
Age *int `json:"age"`
}
// 解析 {"name":"bob"} 后，Name != nil，Age == nil —— 可据此判断 age 是否被提供
嵌套结构解析失败时如何定位具体字段
当 JSON 层级较深（如 {"user":{"profile":{"email":"a@b"}}}），某一层解析失败时，默认错误信息不带路径，只说“expected object but found string”，很难快速定位是 user 还是 profile 出问题。
解决方法有两种：
- 分步解析：先解析外层，再对内层字段单独调用
json.Unmarshal，错误发生时上下文明确 - 自定义
UnmarshalJSON方法，在每个嵌套结构里加字段名前缀，例如：return fmt.Errorf("profile: %w", err)
简单示例（分步）：
var raw map[string]json.RawMessage
if err := json.Unmarshal(data, &raw); err != nil {
return err
}
if profileBytes, ok := raw["profile"]; ok {
var profile Profile
if err := json.Unmarshal(profileBytes, &profile); err != nil {
return fmt.Errorf("failed to unmarshal 'profile': %w", err)
}
}
使用 json.RawMessage 延迟解析的注意事项
json.RawMessage 常用于跳过中间层解析，把某段 JSON 字节原样保留，后续按需解析。但它不是“万能兜底”——如果原始 JSON 不合法（比如多了一个逗号），Unmarshal 仍会失败；而且它只是字节切片别名，**不会做内存拷贝**，如果原始数据被复用或修改，可能导致解析结果意外变化。
- 务必在调用
json.Unmarshal后立刻处理或拷贝json.RawMessage内容 - 不要把它存在长期生命周期的结构体中，除非你控制了原始输入的生命周期
- 若需多次解析同一段 RawMessage，建议用
append([]byte(nil), raw...)先拷贝一份
典型误用：
var msg struct {
Data json.RawMessage `json:"data"`
}
json.Unmarshal(input, &msg)
// 此时 msg.Data 指向 input 的某段内存 —— 如果 input 被重用，msg.Data 可能失效
解析 JSON 错误真正难的不是捕获 error，而是让错误信息带上上下文、让类型判断稳定可靠、让字段语义清晰可验证。尤其在微服务间 JSON 协议频繁变更时，靠 err.Error() 打日志基本等于放弃排查。