json.Decoder比json.Unmarshal更适合大文件，因其绑定io.Reader流式解析、每次只处理一个JSON值、内存稳定在KB级；而Unmarshal需先加载全部JSON到内存，易OOM。
json.Decoder.Decode() 为什么比 json.Unmarshal 更适合大文件
因为 json.Unmarshal 必须接收完整 []byte，你得先调用 os.ReadFile 或 io.ReadAll 把整个文件加载进内存；而 json.Decoder 绑定在任意 io.Reader 上，内部用缓冲 + 状态机，每次只解析一个 JSON 值（比如一个 {} 或 "string"），内存占用稳定在 KB 级别。
常见误用：body, _ := io.ReadAll(resp.Body); json.Unmarshal(body, &v)——这完全绕过了流式能力，和 Python 里 json.load(open()) 一样危险。
真正流式起点：传 *os.File、http.Response.Body、bufio.Reader 给 json.NewDecoder。
如何安全解析 NDJSON（每行一个 JSON）
NDJSON 天然适配 json.Decoder.Decode()：不需要切分、不需跳括号，直接把文件句柄交给 decoder 即可。
立即学习“go语言免费学习笔记（深入）”；
- 别用
bufio.Scanner一行行读再丢给json.Unmarshal——那又回到按行分配内存的老路 -
Decoder.DisallowUnknownFields()仍生效，但它是对每一行单独校验 - 某行 JSON 格式错误时，
err不是io.EOF，必须显式处理，否则循环卡死或 panic - 错误现象
invalid character 'N' looking for beginning of value：通常是文件开头有 BOM 或空行；可用bytes.TrimLeft预处理首段（仅限小文件，大文件别全读）
如何解析顶层是 JSON 数组的大文件（如 [{},{},...]）
这是最易踩坑的场景：decoder.Decode(&slice) 会试图把整个数组解成 Go slice，又爆内存；想逐个解析，必须手动跳过 [，再靠 dec.More() 控制循环边界。
核心逻辑三步：
- 第一步：调
dec.Token()检查并跳过'['——如果返回不是json.Delim('[')，说明格式不对或开头有垃圾字符 - 第二步：进入
for dec.More() { }循环——dec.More()内部会自动识别逗号分隔和结尾']' - 第三步：每次循环内调
dec.Decode(&item)，item可以是map[string]interface{}、自定义 struct 或json.RawMessage
高频错误：invalid character '}' after top-level value 不是语法错，而是 decoder 已退出数组上下文还在继续 Decode()。典型诱因是没在 dec.More() 为 false 后及时 break；调试技巧：循环开头加 if !dec.More() { break }，比依赖 io.EOF 更可靠。
字段动态或结构不一致时怎么保活
日志、ETL 数据常混着不同 "type" 的对象，硬写 struct 容易 panic。此时应把不确定字段声明为 json.RawMessage，延迟解析到真正需要时。
示例：Metadata json.RawMessage `json:"metadata"`，后续用 json.Unmarshal 单独解析该字段，避免全量解码失败。
其他要点：
- 用
struct替代map[string]interface{}能显著减少反射开销和内存分配 - 复用
json.Decoder实例（例如从sync.Pool获取）可降低 GC 压力 - 第三方库如
json-iterator/go或sonic在保持 API 兼容前提下能提速 2–6 倍，但需注意json.RawMessage和Token()行为是否一致
真正的难点不在“能不能解析”，而在“解析出错时是否还能继续”——dec.More() 的边界判断、RawMessage 的延迟策略、以及对非法输入的容忍度设计，才是生产环境里最常被忽略的部分。
