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{} 类型断言。

实操要点：

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 结构体字段必须导出（首字母大写），且带 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 过度设计

真正影响大文件内存表现的，从来不是“要不要用反射”，而是“反射在哪一层、被调用了多少次”。流式解码器 + 无反射结构体生成，才是可控的组合。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！