json.Unmarshal处理大JSON文件必然OOM，因其必须将整个文件加载为[]byte再反射解析，内存占用达文件大小2～3倍；应改用json.NewDecoder配合io.Reader流式解析，内存稳定在KB级。
json.Unmarshal 用反射解析大 JSON 文件必然 OOM
它不是“慢一点”，而是根本不能用：必须把整个文件读成 []byte 才能开始解析，几百 MB 的文件直接吃光内存。哪怕你用 os.ReadFile 分块读、再拼接，json.Unmarshal 仍要求输入是完整合法 JSON，无法跳过开头的 [ 或按需消费流。
常见错误现象：runtime: out of memory、GC 频繁报警、程序卡死在 json.Unmarshal 调用上。这不是 GC 参数能调出来的，是设计限制。
json.Decoder 不走反射路径，但字段访问仍可能触发反射
json.Decoder 本身不依赖反射——它从 io.Reader 流式读取、逐个解码值，内存稳定在 KB 级。但它只是“把字节转成 Go 值”的管道，真正决定是否用反射的是你传给 Decode(&v) 的那个变量 v 的类型。
- 如果你传的是具体结构体指针（如
&MyStruct{}），标准库会用反射遍历字段、匹配 tag、赋值——这部分开销仍在，但只作用于单条记录，不会放大 - 如果你传的是
interface{}或map[string]interface{}，反射开销翻倍：既要解析 JSON 结构，又要动态构造嵌套 map/slice，分配更多临时对象 - 字段越多、嵌套越深、tag 越复杂（比如
json:"user_id,string"），每次Decode的反射成本越高
easyjson 生成代码能彻底绕过运行时反射
它不改你的结构体定义，只在编译前生成专用的 MarshalJSON/UnmarshalJSON 方法。这些方法是纯字段访问 + strconv 拼接，没有 reflect.Value、没有 interface{} 类型断言。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 结构体字段必须导出（首字母大写），且带
json:tag - 注释
//easyjson:json必须独占一行，放在结构体上方 - 运行
easyjson -all models.go生成models_easyjson.go - 后续调用
json.NewDecoder(r).Decode(&v)时，只要v实现了生成的UnmarshalJSON方法，标准库就会自动使用它——无需改框架代码
性能变化：同等结构体下，单次反序列化耗时降为原来的 1/3～1/5，GC 分配减少 90%+，对大文件流式处理尤为明显。
别让 json.RawMessage 成为二次反射的入口
json.RawMessage 把某段 JSON 字节暂存为 []byte，延迟解析——这本身不触发反射。但很多人接着在循环里对同一段 RawMessage 反复调用 json.Unmarshal，等于把一次反射拆成 N 次，还多了一次内存拷贝。
更稳的做法：
- 只在结构体中需要动态判断类型的地方用
json.RawMessage（比如 API 返回的data字段可能是对象或数组） - 一旦确定类型，立刻用对应结构体指针解码一次，别反复解
- 如果该字段固定为某种结构，直接定义具体类型，别用
RawMessage过度设计
真正影响大文件内存表现的，从来不是“要不要用反射”，而是“反射在哪一层、被调用了多少次”。流式解码器 + 无反射结构体生成，才是可控的组合。
