json.Decoder 为什么比 json.Unmarshal 更适合流式嵌套 JSON
因为 json.Decoder 是边读边解析，不把整个输入加载进内存，而 json.Unmarshal 必须拿到完整字节切片才能开始。处理大文件、HTTP 响应流、WebSocket 消息时，后者容易 OOM 或卡死。
常见错误现象：unexpected EOF 或 invalid character '}' after top-level value —— 多半是误把流式数据当单个 JSON 对象传给 json.Unmarshal。
- 适用场景：读取多层嵌套的数组流（如
[{"user":{"profile":{"name":"a"}}},{"user":{"profile":{"name":"b"}}}]）、分块响应、日志行格式 JSON（每行一个对象） - 关键差异：Decoder 不关心顶层结构是否为 object 还是 array；它按 token 流推进，允许你跳过无关字段或提前终止
- 性能影响：Decoder 解析 10MB 嵌套 JSON 流的内存占用通常稳定在几 KB，Unmarshal 则需至少 10MB+ 临时空间
如何用 json.Decoder 逐层进入嵌套结构而不 panic
直接对深层嵌套字段做 struct tag 绑定（比如 type User struct { Profile struct{ Name string } `json:"profile"` }）看似方便，但一旦某层字段缺失或类型错位，Decode 就会报错退出，无法恢复。
真正可控的做法是手动控制 token 流，用 Token() 跳过未知字段、检查键名、进入子对象。
立即学习“go语言免费学习笔记（深入）”；
- 先调
dec.Token()获取第一个 token（通常是{或[），再用循环 + switch 判断后续 token 类型 - 遇到
"user"字符串 token 后，立刻调dec.Token()看下一个是不是{，是就进子对象；不是就用dec.Skip()跳过整段 -
dec.Skip()是关键：它能安全跳过任意深度的嵌套对象或数组，避免手写递归解析逻辑 - 别依赖
json.RawMessage存整个子树——它只是延迟解析，仍会把原始字节全读进内存
处理不固定结构的嵌套 JSON（如混合类型字段、可选层级）
比如 API 返回中 "data" 字段有时是 object，有时是 array，甚至可能是 null —— 这时硬写 struct 会频繁 panic。
正确姿势是分阶段解析：先用 map[string]interface{} 或 json.RawMessage 接住动态部分，再根据实际类型二次解码。
- 用
var v interface{}+dec.Decode(&v)读顶层，再用 type switch 判断v的实际类型（map[string]interface{}/[]interface{}/float64等） - 若确定某字段存在且是 object，可用
json.RawMessage接住，再用新json.Decoder实例解析它——这样既复用流式能力，又隔离错误范围 - 注意：
json.Number默认启用（可通过UseNumber()设置），否则数字会被转成float64导致精度丢失，尤其处理 ID 或时间戳时 - 兼容性坑：Go 1.19+ 默认禁用
DisallowUnknownFields()，但如果你自己封装了解析器，记得显式关闭它，否则未知字段直接报错
Decoder 在 HTTP 流响应中必须注意的连接与错误边界
HTTP/1.1 分块传输或 Server-Sent Events 场景下，json.Decoder 可能中途遇到连接断开、超时或服务端提前关闭，这时 Decode() 返回的 error 不一定是 JSON 格式错误。
必须区分真实解析失败和 I/O 中断，否则可能把网络抖动当成数据异常重试，造成雪崩。
- 检查 error 是否为
io.EOF（正常结束）、io.ErrUnexpectedEOF（非正常中断）、*net.OpError（网络层问题） - 不要在循环里无条件
continue：一次Decode()失败后，decoder 内部状态已损坏，必须新建实例 - 如果上游是
*http.Response.Body，别忘了设置resp.Body.Close()的时机——Decoder 不会自动关它，得你自己控制生命周期 - 流式解析中没有“回滚”机制：token 一旦读走就不可逆，所以字段校验、业务逻辑判断尽量放在 token 流推进过程中，而不是等全解析完再做
嵌套越深，token 层级管理越容易漏掉 Skip() 或多读一个 Token()；这种错误不会立刻报 panic，而是让后续解析偏移，最终表现为字段值错乱或静默丢数据。
