Go原生encoding/json支持嵌套JSON解析，关键在结构体字段类型与嵌套层级严格匹配：嵌套对象用struct，动态结构用map[string]interface{}，深层嵌套宜拆分类型，数组混型用json.RawMessage延迟解析。
Go 语言原生 encoding/json 包完全支持嵌套 JSON 解析，无需额外库——关键在于结构体字段的类型定义是否与嵌套层级严格匹配。
嵌套对象用 struct，不确定结构用 map[string]interface{}
JSON 中的嵌套对象（如 {"user": {"name": "Alice", "age": 30}}）最稳妥的方式是定义对应嵌套 struct。但如果字段动态、未知或部分可选，直接用 map[string]interface{} 更灵活，但会失去类型安全和编译期检查。
- 固定结构优先定义 struct：字段名首字母大写（导出），并加
json:tag 显式映射键名 -
map[string]interface{}适合快速探查或中间层转发，但后续取值需断言（如v["user"].(map[string]interface{})），容易 panic - 混合使用常见：外层 struct，内层某字段设为
map[string]interface{}或json.RawMessage延迟解析
深层嵌套时避免 struct 定义爆炸
遇到多层嵌套（如 {"data": {"list": [{"item": {"id": 1}}]}}），不要强行展开成四级 struct。合理使用匿名字段、嵌入或中间类型能大幅降低维护成本。
- 用
type Item struct { ID int }+type List []Item拆分，比写Data struct { List []struct{ Item struct{ ID int } } }清晰得多 - 若某层纯作容器无业务含义（如
"result"或"payload"），可忽略该层，用json:"result" UnmarshalJSON方法自定义解码逻辑 - 注意：空嵌套对象（
{}）被解到 struct 会成功，但字段全零值；解到map[string]interface{}则得到空 map，二者行为不同
数组嵌套中混入不同结构？用 json.RawMessage 缓存再判断
当 JSON 数组里元素类型不一致（如 [{"type":"user","name":"A"},{"type":"admin","level":9}]），直接解到统一 struct 会失败。此时应先用 json.RawMessage 把每个元素原样保留，再根据 type 字段做分支解析。
立即学习“go语言免费学习笔记（深入）”；
-
json.RawMessage是[]byte别名，不触发解析，零拷贝保留原始字节 - 必须在 struct 中声明为字段类型，不能用于局部变量直接
json.Unmarshal - 示例字段定义：
Items []json.RawMessage `json:"items"`，之后遍历每个item，先json.Unmarshal(item, &t)到临时 struct 判断Type，再二次解码
Unmarshal 后 nil slice 和空 slice 的区别很关键
JSON 中 "items": null 与 "items": [] 在 Go struct 中表现完全不同：前者导致 slice 字段为 nil，后者是长度为 0 的非 nil slice。很多逻辑（如 len(items) == 0）对两者都成立，但 items == nil 判断不可省略。
- 反序列化时，
null→ 字段保持零值（nilslice /nilmap /nilpointer） - 若希望
null也转为空 slice，可自定义UnmarshalJSON方法，或用指针类型字段（如*[]string）配合判空处理 - 第三方库如
github.com/mitchellh/mapstructure默认把null当空值处理，行为与标准库不一致，切换前务必验证
嵌套 JSON 解析真正的难点不在语法，而在于对 JSON 数据源稳定性的误判——比如后端悄悄新增一个嵌套字段，或把数组改成对象，Go 的强类型会在运行时才暴露问题。上线前用真实响应体做反向测试，比写一堆泛型适配更有效。
