json.decoder能避免内存爆炸，因其是流式解析器，边读字节流边解码，仅需几kb缓冲区；而json.unmarshal需加载完整json到内存，大文件易触发oom。
json.Decoder 为什么能避免内存爆炸
因为 json.Decoder 是流式解析器，它不把整个 JSON 文本读进内存再解析，而是边读字节流边解码——哪怕文件几百 MB，它也只用几 KB 的缓冲区。而 json.Unmarshal 必须拿到完整 []byte 才开始工作，大 JSON 直接触发 OOM。
典型误用场景：用 ioutil.ReadFile（或 os.ReadFile）读取一个 500MB 的日志 JSON 文件，再传给 json.Unmarshal —— 这时 Go 进程内存瞬间飙到 1GB+，然后被系统 kill。
- 流式处理只在数据源是
io.Reader（如*os.File、net.Conn、bytes.Reader）时生效 -
json.Decoder内部默认使用 4KB 缓冲，可通过bufio.NewReaderSize(r, size)调整，但一般不用动 - 它对 JSON 格式要求更严格：必须是合法的单个 JSON 值（对象/数组），不能是多个并列的 JSON（如两行 JSON 对象）
如何安全解码超大 JSON 数组（如日志列表）
常见需求：一个文件里存了成千上万个 JSON 对象，每行一个（NDJSON）或包在一个大数组里（[{...},{...},...]）。前者用 json.Decoder + 循环最稳；后者得先跳过 [，再逐个解码，直到遇到 ] 或 EOF。
关键点：别试图把整个数组解成 []map[string]interface{}，那是自找死路。
立即学习“go语言免费学习笔记（深入）”；
- 对于 NDJSON（每行一个 JSON）：
scanner := bufio.NewScanner(f)配合json.Unmarshal单行解码，简单可靠 - 对于包裹型大数组：
dec := json.NewDecoder(f)，先调用dec.Token()消耗开头的[，再用for dec.More() { dec.Decode(&item) } -
dec.More()是安全边界——它在每次Decode前检查是否还有下一个值，遇到]自动返回 false，不会 panic
Decoder.Decode() 返回 io.EOF 就代表结束？不一定
io.EOF 只说明输入流到底了，但不等于 JSON 解析成功完成。比如文件末尾突然中断（{"name":"alice" 缺少 }），Decode() 会返回 Unexpected EOF，不是 io.EOF。
真正该检查的是错误类型，而不是只看是不是 io.EOF。
- 正确做法：
if err != nil { if errors.Is(err, io.EOF) || errors.Is(err, io.ErrUnexpectedEOF) { break } else { log.Fatal(err) } } -
json.SyntaxError表示格式错（如多逗号、引号没闭合），这种错误要具体打印err.Error()和出错位置（.Offset）才好定位 - 如果解码目标 struct 字段类型和 JSON 值不匹配（比如 JSON 传字符串，struct 字段是
int），Decode()返回json.UnmarshalTypeError，不是 panic
嵌套结构 + 流式解码的坑：字段没声明为指针就收不到值
当 JSON 里某个字段是可选（可能为 null），又想区分“字段缺失”和“字段为 null”，必须用指针类型。否则 Decode() 把零值写进去，你就永远不知道原始 JSON 到底有没有这个 key。
例如：{"user":{"name":"bob"}} 和 {"user":null} 在下面两种定义下行为完全不同：
type Resp struct {
User User `json:"user"`
}
type User struct {
Name string `json:"name"`
}
此时 User 字段永远不是 nil，null 会被静默转成零值 User{}。换成指针才能捕获语义差异：
type Resp struct {
User *User `json:"user"`
}
- 所有可能为
null的嵌套对象、数组、数字、布尔字段，都建议用指针类型（*string、*[]int等） - 注意：指针字段在 JSON 中为
null时，Decode()会设为nil；字段完全缺失时，也是nil——仍需靠json.RawMessage或预扫描 Token 来区分 - 性能影响极小，指针本身只占 8 字节，且避免了不必要的零值初始化
