json.Unmarshal会一次性将整个JSON加载进内存，处理几百MB文件易引发OOM；而json.Decoder支持流式解析，配合json.RawMessage可按需解码顶层字段、跳过无关部分，内存占用可控。
为什么不能直接用 json.Unmarshal 加载几百 MB 的配置文件
Go 的 json.Unmarshal 会把整个 JSON 字符串一次性解析成内存中的结构体，如果配置文件有 500MB，它至少需要 1.5–2GB 内存（JSON 字符串 + 解析后对象），还容易触发 GC 压力或直接 OOM。这不是配置设计问题，是加载方式错了——你不需要一口气把所有配置都变成 Go 对象。
用 json.Decoder 流式读取顶层字段
标准库的 json.Decoder 支持边读边解析，配合 json.RawMessage 可以只解出你当前需要的段落，其余部分跳过或延迟处理。关键不是“分段”，而是“按需解码顶层键”。
假设你的大配置长这样：
{
"database": { ... },
"services": { ... },
"features": { ... },
"logging": { ... }
}
你可以这么做：
立即学习“go语言免费学习笔记（深入）”；
- 打开文件句柄，传给
json.NewDecoder - 调用
decoder.Token()找到"database"键，再用json.RawMessage捕获其值（不立刻解析） - 仅对需要的段落（比如只加载
database）调用json.Unmarshal - 其余字段用
decoder.Skip()快速跳过，避免构造中间对象
map[string]json.RawMessage 是最轻量的“分段入口”
如果你知道配置结构固定、且只在启动时读几个段，直接解成 map[string]json.RawMessage 是最快路径。它不校验字段类型，不递归解析，只是切分 JSON 的 key-value 对，内存开销≈原始字节长度 × 1.1。
示例：
var sections map[string]json.RawMessage err := json.NewDecoder(f).Decode(§ions) // sections["database"] 是原始 JSON 字节，可复用多次或传给子模块单独解
注意点：
- 必须确保顶层是 object（不是 array），否则 panic
-
json.RawMessage是[]byte别名，别在 goroutine 间共享同一份数据并并发修改 - 如果某段后续要多次解析（比如被多个组件用），建议解一次缓存为 struct，别反复
Unmarshal
真正需要“分段加载”的场景：配置热更新 + 按需重载
纯启动加载用不上“分段”，除非你支持运行时 reload 某个模块配置（比如动态开关某个 service）。这时推荐用 sync.Map + 文件监听 + 段落级锁：
- 每个配置段（如
"services"）对应一个sync.Map或 struct 指针 - 监听文件变更后，只重新解码变更段，用
atomic.StorePointer替换老指针 - 读侧用
atomic.LoadPointer获取当前版本，零拷贝、无锁读
别用 os.ReadFile 全量重读——那是退化回原始问题；也别在 reload 时锁整个配置 map——会卡住所有读请求。
最易被忽略的是：json.RawMessage 中的字符串字段仍是 UTF-8 字节，没做转义还原；如果你要提取其中某个小字段（比如 database.host），别手写 byte slice 截取，老实用 json.Unmarshal 再套一层——安全比省那几微秒重要得多。
