json.unmarshal解析失败时返回具体错误类型而非仅nil，如json.syntaxerror、json.unmarshaltypeerror等，需用类型断言区分处理。
JSON解析失败时，json.Unmarshal返回什么错误
json.Unmarshal 在遇到格式错误、类型不匹配或结构体字段不可导出等场景时，会返回非 nil 的 error。常见错误值包括：json.SyntaxError（非法字符、括号不匹配）、json.UnmarshalTypeError（比如把字符串塞进 int 字段）、json.InvalidUnmarshalError（传了 nil 指针或非指针）。这些错误类型都实现了 error 接口，但**不能只用 err != nil 判断后就忽略细节**——很多线上问题源于没区分是数据脏还是代码错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用类型断言提取具体错误：例如
if serr, ok := err.(*json.SyntaxError); ok { log.Printf("syntax error at byte %d", serr.Offset) } - 对关键字段做预校验：比如先用
json.Valid()快速过滤明显非法 JSON，避免后续解析开销 - 避免在循环中反复调用
json.Unmarshal解析同一份数据——可提前解包一次，缓存结果
结构体字段未导出导致解析静默失败
Go 的 json 包只能设置**首字母大写的导出字段**。如果结构体里写的是 name string（小写），即使 JSON 里有 "name":"foo"，解析也不会报错，但该字段始终为空值。这种“无提示失败”最容易被忽略，尤其在调试 API 响应时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有需 JSON 映射的字段必须首字母大写，并通过
json:"name"标签显式声明键名 - 启用
json.Decoder.DisallowUnknownFields()防止未知字段混入（注意：它对顶层对象生效，嵌套结构需手动处理） - 用
json.Marshal反向序列化再比对原始字节，快速验证字段是否真被写入
处理缺失字段与零值的边界情况
JSON 中字段缺失（如 {"age":25} 没有 name）和字段存在但为 null（{"name":null}）在 Go 解析后表现不同：前者对应结构体字段保持零值；后者若字段是 *string 或 sql.NullString 才能捕获 null。但直接用 string 类型时，null 会触发 json.UnmarshalTypeError。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要区分“未提供”和“明确设为 null”时，字段类型必须用指针（
*string）或自定义类型（如实现UnmarshalJSON方法） - 对可选字段，避免在结构体定义里加
omitempty标签——那是控制序列化行为的，不影响反序列化 - 用
map[string]interface{}临时解析再手动判断键是否存在，适合动态字段场景，但性能较差，别在高频路径用
性能敏感场景下如何避免重复解析
频繁解析相同 JSON 字符串（比如配置文件、HTTP 请求体）会反复分配内存、遍历字节流。标准库的 json.Unmarshal 每次都从头解析，没有内置缓存机制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对静态 JSON（如配置项），启动时解析一次，存为全局变量或依赖注入对象
- 对请求体，用
io.ReadCloser包装后，先读取到[]byte，再复用该字节切片进行多次json.Unmarshal（注意别跨 goroutine 共享，避免并发写） - 极端性能要求下，考虑用
github.com/json-iterator/go替代标准库，它支持复用Decoder实例、跳过反射、甚至预编译结构体绑定
最常被绕过的点是：以为加了 omitempty 就能控制反序列化逻辑，其实它只影响 Marshal；还有人把 json.RawMessage 当万能解药，却忘了它只是延迟解析，真正用到时照样可能 panic —— 这些地方一松懈，就是半夜告警的源头。
