最稳、最可维护的解法是直接用导出结构体嵌套加精准json标签映射；字段必须首字母大写且显式声明json:"key"，不可依赖命名巧合或点路径；动态key用map[string]T，异构数组用[]json.RawMessage延迟解析。
直接用结构体嵌套 + json 标签映射，是最稳、最可维护的解法；别先转 map[string]interface{}，那只是把类型检查和 panic 推迟到运行时。
嵌套结构体字段必须导出且带 json 标签
Go 的 encoding/json 包只认首字母大写的导出字段，小写字段（如 name string）永远解析失败，值保持零值。同时，API 返回的 key 多为 snake_case，而 Go 字段习惯 CamelCase，不加标签就完全对不上。
-
json:"user_id"显式绑定，不能省；即使字段名碰巧一致（如Name↔"name"），也建议写上，避免重命名后静默失效 - 嵌套对象必须用 struct，不能靠
json:"user.name"这种路径式标签——json包不支持点号路径解析 - 空对象
{}解到 struct 会成功但字段全为零值；解到map[string]interface{}得到空 map，行为不同，别混用
动态 key（如日期、ID 字符串）必须用 map[string]T
当 JSON 的 key 是运行时才确定的（例如 {"2024-01-01": {...}, "2024-01-02": {...}}），struct 字段无法预先定义。这时只能退到 map[string]T，其中 T 是你已知结构的命名类型。
- 别用
map[string]interface{}然后层层断言——v["data"].(map[string]interface{})["items"].([]interface{})[0].(map[string]interface{})["id"]这种链式断言极易 panic - 优先定义
type DailyReport struct { ... }，再声明字段为Daily map[string]DailyReport `json:"daily"` - 若 value 结构也不固定，可用
map[string]json.RawMessage缓存原始字节，后续按需解析，避免重复解码开销
数组里混着不同结构？用 json.RawMessage 延迟解析
JSON 数组元素类型不一致（如 [{"type":"user"}, {"type":"admin","level":9}]）时，强行解到统一 struct 会失败或丢数据。正确做法是先保留原始字节，再根据 type 字段分支处理。
- 字段定义写成
Items []json.RawMessage `json:"items"`，json.RawMessage是[]byte别名，零拷贝 - 遍历每个
json.RawMessage，先json.Unmarshal到一个只含Type string的临时 struct 判断类型 - 再二次解码到对应目标 struct，比如
User或Admin，避免字段冲突和静默忽略 - 注意：
json.RawMessage必须作为 struct 字段类型使用，不能用于局部变量直接传给json.Unmarshal
要不要用 gjson？看场景，别滥用
gjson 适合快速提取、调试、日志打点或中间层转发这类“只读不建模”的场景。它用点语法（"user.profile.theme"）一行取值，性能好、零分配。但它不提供类型安全，也不生成可测试、可复用的领域模型。
- 对外部不可信 JSON，务必先调
gjson.Valid(json)，否则gjson.Get(...).String()可能返回空字符串，掩盖真实缺失 - 存在性判断必须用
result.Exists()，而不是result.String() != ""——空字符串本身是合法值 - 如果业务逻辑需要校验、方法、嵌入、接口实现或单元测试，还是得回到 struct +
Unmarshal路线
真正容易被忽略的是：嵌套层级越深，越要克制“一股脑展开”的冲动。比如 {"data":{"list":[{"item":{"id":1}}]}}，与其定义 Data、List、Item 四个 struct，不如把 data.list 直接映射为 []Item，用 json:"data.list"？不行——Go 不支持路径标签。唯一办法是接受中间层，或用自定义 UnmarshalJSON 方法跳过无意义容器字段。
