Go 的 json.Unmarshal 易因类型不匹配或字段模糊导致静默丢数据，需检查 error 类型并用 map[string]interface{}、json.RawMessage 等灵活处理动态结构与异常格式。
Go 标准库的 encoding/json 足够强大，但直接用 json.Unmarshal 处理不规范、嵌套深或字段类型模糊的 JSON，十有八九会 panic 或静默丢数据。
JSON 解析失败却没报错？检查 json.Unmarshal 的 error 返回值
很多新手把 json.Unmarshal 当成“解析成功就填值，失败就不管”，其实它对部分字段解析失败（比如字符串赋给 int 字段）可能只返回 nil 错误，而目标结构体对应字段保持零值——看起来像“解析成功”，实则数据已丢失。
- 务必检查
err != nil，且不要忽略err的具体类型：常见如json.SyntaxError（格式错误）、json.UnmarshalTypeError（类型不匹配） - 若源 JSON 字段名大小写不固定（如
"user_id"和"userId"混用），别硬套 struct tag，先用map[string]interface{}做过渡解析，再按需转换 - 避免用空 struct（
struct{}）接收未知结构，它无法解码任何字段；改用json.RawMessage延迟解析不确定部分
处理动态 key 或可选字段：优先用 map[string]json.RawMessage
当 JSON 中存在“每条记录 key 不同”（如监控指标数据：{"cpu_usage": 85, "mem_used_mb": 2048}）或“某些字段只在特定条件下出现”，强行定义 struct 会导致大量指针字段和冗余判断。
- 声明为
map[string]json.RawMessage，能原样保留未解析的 JSON 片段，后续按 key 名决定是否解析、用哪种 struct 解析 - 注意：
json.RawMessage是[]byte别名，不可直接打印或比较，需转string()或再次json.Unmarshal - 如果 key 是数字字符串（如
{"2024-01": {...}, "2024-02": {...}}），用map[string]json.RawMessage比自定义UnmarshalJSON方法更轻量
性能敏感场景：避免重复序列化/反序列化
工具类程序常需“读 JSON → 改字段 → 写回 JSON”，若每次修改都走 json.Marshal + json.Unmarshal 全量重解析，小数据无感，一旦单次处理几百 KB 以上 JSON，CPU 和内存开销明显上升。
立即学习“go语言免费学习笔记（深入）”；
- 对频繁修改的字段，用
map[string]interface{}或map[string]json.RawMessage作为中间表示，仅对变更部分调用json.Marshal - 若只是增删字段、不改嵌套结构，可用
bytes.ReplaceAll或正则做字符串级 patch（仅限确定格式、无转义风险时） - 标准库不支持“部分解析”，如真需高性能随机访问，考虑第三方库
go-json或gjson（后者专用于只读查询，不构建完整对象）
真正难的不是解析语法正确的 JSON，而是应付那些“看似合法、实则字段语义飘忽”的数据源——比如时间字段有时是字符串、有时是毫秒整数、有时是空字符串。这时候 struct tag 和类型断言救不了你，得靠 json.RawMessage + 显式类型检查兜底。
