结构体嵌套必须严格对齐json层级，外层字段首字母大写并显式加json标签；动态键名或混型数组应使用json.rawmessage暂存，避免map[string]interface{}链式断言；流式解码推荐json.newdecoder逐行处理大文件。
直接用 encoding/json 解复杂嵌套 JSON，不靠框架也能稳；所谓“框架解析技巧”，多数是把类型系统绕开后又手动补救，反而增加 panic 风险。
结构体嵌套必须严格对齐 JSON 层级
JSON 里有几层对象，Go 里就得有几层 struct。比如 {"data":{"items":[{"id":1}]}}，不能只写一个顶层 struct 加 []Item 字段。
- 外层字段名必须首字母大写，且显式加
json:"data"标签 -
Items字段类型设为[]Item，不是[]interface{} - 别把
"data"这种纯容器字段塞进业务逻辑，用结构体字段名承载语义（如Data或ResponseData） - 小写字段（如
userID string）永远解析失败，值保持零值，且不报错——这是最隐蔽的坑
动态键名或混型数组必须用 json.RawMessage
当键名不确定（如 {"2024-01-01": {...}}）、或数组元素类型不一致（如 [{"type":"user"}, {"type":"admin","level":9}]），硬套 struct 必 panic。
- 字段声明为
Children json.RawMessage `json:"children,omitempty"`，不是interface{}也不是map[string]interface{} -
json.RawMessage是[]byte别名，零拷贝、不触发类型检查，只做字节暂存 - 后续按需调用
json.Unmarshal：先解出Type字段判断分支，再二次解到对应 struct - 别在局部变量里直接用
json.RawMessage—— 它只能作为 struct 字段类型使用
避免 map[string]interface{} 链式断言
像 v["data"].(map[string]interface{})["items"].([]interface{})[0].(map[string]interface{})["id"] 这种写法，只要中间任一字段缺失或类型不符，立刻 panic。
- 如果只是临时探查或转发，可用
map[string]interface{}，但仅限一层 - 若需复用某子结构，定义具体类型（如
type DailyReport struct{...}），再声明字段为Daily map[string]DailyReport `json:"daily"` - 空对象
{}解到 struct 得全零值；解到map[string]interface{}得空 map —— 行为不同，别混用 - 字段可选时，用指针类型（如
*string）比omitempty更可控，能区分“未设置”和“设为空字符串”
流式解码适合大文件或行格式 JSON
面对日志类 JSON 文件（每行一个对象）或内存受限场景，json.Unmarshal 会一次性加载全部内容，容易 OOM。
- 用
json.NewDecoder逐行读取：decoder.Decode(&log)，避免整文件加载 -
json.NewDecoder可直接读os.File或http.Response.Body，无需先转[]byte - HTTP 响应体不可重复读，别在
Decode前调用Body.Read或ioutil.ReadAll - 流式解码不支持跳过字段，所有字段仍需类型匹配；动态部分仍得靠
json.RawMessage暂存
真正复杂的点不在“怎么解”，而在“哪一层该信任类型系统，哪一层该主动放弃”。越往深层走，越要克制用 interface{} 的冲动——json.RawMessage 是唯一既保留原始字节又不破坏类型边界的锚点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
