json.Unmarshal不能处理大JSON文件，因其必须将整个JSON一次性加载为[]byte进内存，易触发OOM或GC压力；而json.Decoder基于io.Reader流式解析，每次只解一个值，内存稳定在KB级。
json.Unmarshal 为什么不能直接处理大 JSON 文件
json.Unmarshal 要求整个 JSON 数据必须提前加载到内存中，作为 []byte 传入。对几百 MB 甚至 GB 级别的 JSON 文件，这会瞬间吃光可用内存，触发 OOM 或严重 GC 压力；更糟的是，哪怕文件只是“逻辑上大”（比如一个顶层数组含数万对象），json.Unmarshal 仍会试图一次性解析全部内容，无法流式消费。
常见错误现象：runtime: out of memory、程序卡死、GC 频繁报警。
- 别把
os.ReadFile和json.Unmarshal组合用于大文件——这是最典型的误用 - 即使你手动分块读取字节再拼接，也无法绕过
json.Unmarshal对完整合法 JSON 的强依赖 - 如果 JSON 是数组格式（如
[{...},{...},...]），json.Unmarshal会尝试构建整个切片，内存占用与元素数量线性增长
用 json.Decoder 替代 Unmarshal 实现流式反序列化
json.Decoder 是标准库为流式场景设计的替代方案，它从 io.Reader（如文件、HTTP body）边读边解析，不缓存整棵 JSON 树，单次只解码一个值。
关键点：它天然支持“逐个解码数组元素”，无需预知数组长度或提前加载全部数据。
立即学习“go语言免费学习笔记（深入）”；
- 打开文件后，用
json.NewDecoder(file)创建解码器实例 - 若 JSON 是数组，先调用
decoder.Token()消费[，再循环调用decoder.Decode(&item) - 每次
Decode只分配一个结构体实例的内存，复用变量可进一步减少 GC - 遇到无效 JSON 时，
Decode返回具体错误（如json.SyntaxError），位置信息比Unmarshal更准
示例片段：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
file, _ := os.Open("big.json")
defer file.Close()
decoder := json.NewDecoder(file)
// 跳过开头的 '['
if t, _ := decoder.Token(); t != json.Delim('[') {
log.Fatal("expected [")
}
var item MyStruct
for decoder.More() {
if err := decoder.Decode(&item); err != nil {
log.Printf("decode error: %v", err)
continue // 或 break，取决于容错策略
}
process(item) // 处理单条记录
}
处理未知结构或混合类型时用 json.RawMessage 延迟解析
当大 JSON 中某些字段结构动态变化（如 API 返回的 data 字段可能是对象也可能是数组），硬编码结构体会导致反序列化失败。此时 json.RawMessage 把原始字节暂存为 []byte，等真正需要时再按需解析。
它避免了为每种可能结构定义多个类型，也防止提前解析浪费 CPU。
- 字段声明为
Data json.RawMessage `json:"data"` - 后续用
json.Unmarshal(data, &target)解析该字段，可复用同一decoder实例 - 注意：
json.RawMessage不做语法校验，非法 JSON 会在后续Unmarshal时才暴露 - 不适合嵌套过深的场景——多次嵌套
RawMessage会让代码难以维护
性能敏感场景考虑 jsoniter 替代标准库
标准库 encoding/json 在解析速度和内存分配上并非最优。实测显示，jsoniter 在大文件场景下通常快 2–5 倍，且 GC 分配更少。
但它不是“开箱即用”的 drop-in 替换——部分高级行为（如自定义 MarshalJSON 方法）需额外适配。
- 导入替换：
"github.com/json-iterator/go"，并用jsoniter.ConfigCompatibleWithStandardLibrary初始化 - 保持原有结构体标签和调用方式，
jsoniter.Unmarshal和jsoniter.NewDecoder接口一致 - 注意：第三方库引入会增加二进制体积和依赖风险，仅在压测确认瓶颈在 JSON 解析时启用
- 别忽略
jsoniter对time.Time等类型的默认行为差异，需显式配置
真正的大文件反序列化难点不在“怎么写”，而在“怎么控制边界”：是否允许跳过坏记录？如何限速避免压垮下游？json.Decoder 提供了基础能力，但容错、并发、监控这些，得靠你自己补全。
