正确做法是定义匹配的嵌套 struct，字段首字母大写、json tag 与 JSON 键名严格一致；可能为 null 的字段用指针类型；不固定 key 用 map[string]T；混类型字段实现 UnmarshalJSON；性能敏感时用 json.RawMessage 延迟解析。
用 json.Unmarshal 直接解析嵌套结构，但必须定义匹配的 struct
Go 不支持“动态路径取值”式解析（比如像 Python 的 data['a']['b']['c']），所有嵌套字段都得提前在 struct 中声明。常见错误是直接用 map[string]interface{} 套娃，结果越跑越深、类型断言爆炸、还容易 panic。
正确做法：把 JSON 的每一层结构对应到 struct 字段，用指针或嵌套 struct 表示层级关系。例如：
type User struct {
Name string `json:"name"`
Info Info `json:"info"`
}
type Info struct {
Age int `json:"age"`
Addr Address `json:"address"`
}
type Address struct {
City string `json:"city"`
Zip string `json:"zip"`
}
然后调用：json.Unmarshal(data, &user) —— 只要字段名和 tag 对得上，Go 就能一层层解出来。
- 字段首字母必须大写（否则
json包无法反射访问） - struct tag 中的
json键名要和 JSON 字段完全一致（注意大小写、下划线） - 如果某层可能为
null，对应字段建议用指针类型（如*Info），避免零值覆盖语义
遇到不固定 key 名的嵌套对象（比如 ID 作为 key），用 map[string]T
当 JSON 是类似 {"123": {"name": "a"}, "456": {"name": "b"}} 这种“ID → 对象”结构时，不能硬写 struct，得用 map。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操上，先定义好值类型（比如 type Item struct { Name string } ），再声明 map[string]Item 或 map[string]*Item（后者可区分空对象和缺失 key）。
- 别用
map[string]interface{}接收后再手动转——类型丢失、易出错、无编译检查 - 如果 key 是数字字符串但业务上要当 int 用，解析后额外做
strconv.Atoi，别试图让json包自动转 key 类型（它不会） - map 的 key 必须是可比较类型（string、int 等），不能是 slice 或 struct
部分字段缺失或类型不一致导致 json: cannot unmarshal ...
这个错误最常出现在：JSON 里某个字段本该是 object，但 API 返回了 null；或者字段有时是 string，有时是 number（比如 "count": 5 和 "count": "5" 混用）。
Go 的 json 包默认严格校验类型，不兼容这种松散格式。解决方式不是改包，而是适配数据现实：
- 对可能为
null的嵌套对象，字段声明为*T（如Info *Info） - 对可能混类型的字段（如 string/number），用自定义类型 +
UnmarshalJSON方法（实现时先读成json.RawMessage，再分支解析） - 加
omitemptytag 不影响反序列化，只控制序列化输出；缺失字段默认设为零值，不是跳过
性能敏感场景下，避免反复解析同一段 JSON 多次
如果一段 JSON 要被多个函数分别取不同字段，别每次 json.Unmarshal 到不同 struct —— 解析本身有开销，而且重复分配内存。
更稳的做法：一次解析到一个“全量 struct”，然后各函数按需读它的字段。如果字段太多、又怕内存浪费，可用 json.RawMessage 延迟解析：
type Event struct {
ID int `json:"id"`
Detail json.RawMessage `json:"detail"` // 先存原始字节，需要时再 Unmarshal
}
-
json.RawMessage本质是 []byte，不触发解析，也不拷贝内容（只是切片引用） - 但它不会帮你校验格式，后续
Unmarshal仍可能 panic，得包recover或提前检查 - 别把它当通用“懒加载”方案——字段访问频率高、结构稳定时，直解析 struct 更清晰、更安全
gojson）减负。 
