json.unmarshal不适合大数据场景，因它一次性加载全部json到内存并递归构建完整对象，100mb文件常耗300mb+内存，且无法跳过无关字段；应改用流式token解析、gjson零拷贝路径提取或jsonparser极致零分配提取等替代方案。
直接用 encoding/json 解大文件或流数据，内存会炸、gc 会抖、解析慢——这不是配置问题，是设计模式错了。真要高性能，得绕开全量反序列化，从解析模型本身换思路。
为什么 json.Unmarshal 不适合大数据场景
它把整块 JSON 字节一次性读进内存，再递归构建 map[string]interface{} 或 struct，100MB 文件常吃掉 300MB+ 内存。更糟的是，哪怕你只想要 "user.id"，它也得把 "user.profile.settings.theme" 全部展开、分配、赋值。
- 错误现象：
json.Unmarshal(data, &v)后再用v.User.ID取值——看似省事，实则没跳过任何字段，性能和内存毫无优化 - 适用场景：小体积、结构固定、QPS 低的配置加载或 RPC 响应体
- 替代思路：用流式 token 推进（
json.Decoder.Token()）或零拷贝路径提取（gjson.Get()、jsonparser.GetString()）
用 gjson 实现“一行取值”式解析
适合日志分析、API 网关字段透传、CLI 工具等需要快速提取固定路径的场景。它不建树、不反射、不分配新内存，直接在原始 []byte 上游走指针。
- 必须用
gjson.GetBytes(data, "user.name")，别用gjson.Get(string(data), ...)——避免string转换开销 - 嵌套数组用
"items.#.id"，条件过滤写成"users.#(age>25).name"，但注意：条件表达式越复杂，CPU 开销越明显 - 永远先调
val.Exists()判断字段是否存在，val.String() != ""会误判空字符串合法值 - 性能基准：约
200ns/次，无 GC 分配，高并发下稳如
用 jsonparser 做极致零分配字段提取
当你的服务每秒处理数万条 IoT 设备上报（每条含 "ts", "device_id", "metrics.cpu"），且不允许任何 heap 分配时，github.com/buger/jsonparser 是目前最硬核的选择。
- 调用方式极简：
jsonparser.GetInt(data, "metrics", "cpu")，路径支持多级，失败直接返回 error，不 panic - 它不 parse 整个 JSON，只扫描字节流匹配 key 的 UTF-8 序列，所以比
gjson还快（尤其单字段）、内存占用更低（纯栈操作） - 不能处理通配符或条件查询；也不支持
"metrics.*.value"这类模糊路径——它只认精确 key 名 - 脏数据容忍弱：若 key 名含非法字符（如控制符），会直接报
InvalidCharacterError，建议前置校验json.Valid()
用 json.Decoder + bufio.Scanner 处理 NDJSON 流
日志系统、Kafka 消费、Nginx JSON 日志等典型场景，数据是“每行一个 JSON 对象”，这时不能把整个文件丢给一个 json.Decoder——它读完第一个对象就 EOF 了。
- 必须为每一行新建
json.NewDecoder(strings.NewReader(line))，复用实例会导致状态错乱、解析失败 - 加行长度限制：
if len(line) > 1024*1024 { continue }，防止单行畸形 JSON 耗尽内存 - 解析失败时，打印
fmt.Sprintf("line %d: %.100s", lineno, line)，方便定位哪一行坏了 - 如果字段名已知且固定，别用
decoder.Decode(&m)解到map[string]interface{}——改用手动Token()推进，跳过无关 key，速度能再提 3–5 倍
真正卡性能的往往不是库选错，而是混合用了多种模式：比如一边用 gjson 提字段，一边又用 json.Unmarshal 解同一份数据做校验。字段路径越明确、越静态，就越该压到零分配路径；结构稍复杂但稳定，jsoniter 或 fastjson 的 struct 绑定反而更省心。没有银弹，只有对齐场景的取舍。
