jsoniter.Unmarshal 在多数简单场景下比 encoding/json 快 1.5–3 倍，但结构复杂、含指针/接口或自定义反序列化时优势减弱；Go 1.20+ 标准库已大幅优化小结构体性能，差距缩至 10% 内。
jsoniter.Unmarshal 比 encoding/json.Unmarshal 快，但不是所有场景都成立
直接结论：在多数结构体嵌套不深、字段名较短、无自定义 UnmarshalJSON 方法的场景下，jsoniter.Unmarshal 能比标准库快 1.5–3 倍；但如果结构体含大量指针、接口字段或频繁调用自定义反序列化逻辑，两者差距会缩小甚至反转。
原因在于 jsoniter 默认启用「代码生成模式」（需提前运行 jsoniter-gen）时会绕过反射，而标准库全程依赖 reflect。但若没开代码生成，jsoniter 仍走反射路径，仅靠更精简的 parser 实现小幅提升。
- 实操建议：先用
go test -bench=.对比真实业务 payload，别只测空对象或单层 map - 注意 jsoniter 默认不兼容
time.Time的 RFC3339 解析（标准库默认支持），需显式注册jsoniter.RegisterTimeUnmarshaler - 若项目已用
encoding/json的json.RawMessage做延迟解析，jsoniter 的jsoniter.RawMessage行为略有差异——它不保留原始字节，而是解析成内部 token 流，后续再取值才真正 decode
jsoniter 的配置必须全局生效，且影响所有后续调用
jsoniter 的配置项（比如 ConfigCompatibleWithStandardLibrary、DisallowUnknownFields）是通过 jsoniter.Config 构建新实例，再用 jsoniter.Config.Marshal 等方法调用——但很多人误以为设一次就全局生效，其实不是。
真正影响全局行为的是 jsoniter.ConfigDefault，它是包级变量，所有未指定 config 的 jsoniter.Unmarshal/jsoniter.Marshal 都会 fallback 到它。一旦你执行了 jsoniter.ConfigDefault = myCfg，整个进程里所有后续未显式传 config 的调用都会被改变。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误：在 init 函数里改了
ConfigDefault，结果测试用例里某个地方悄悄用了encoding/json的 tag 规则（如json:"name,omitempty"），却因 jsoniter 的默认 strict mode 报错unknown field "name" - 推荐做法：业务代码中统一用带 config 的版本，例如
jsoniter.ConfigCompatibleWithStandardLibrary.Marshal，避免污染全局状态 - 性能提示：启用
DisallowUnknownFields会增加字段校验开销，在已知数据干净的场景（如内部 RPC）可关掉
StdLib 的 streaming 解析能力更稳定，jsoniter 的 Decoder 接口有隐藏限制
当处理大 JSON 流（如 HTTP body 或文件）时，encoding/json.Decoder 支持按需解析、内存可控；jsoniter 也提供了 jsoniter.NewDecoder，但它底层仍会预读部分 buffer，且对「流中混杂非 JSON 数据」的容错性不如标准库。
典型问题：用 jsoniter.NewDecoder 解析一个以 {"data": [...]} 开头的响应体，如果 [...] 是超大数组，jsoniter 可能提前分配过多内存，而标准库的 Decoder.Token() 可以逐个跳过元素。
- 实操建议：需要精确控制内存或处理不确定长度的数组/对象流时，优先用
encoding/json.Decoder+Token()手动遍历 - jsoniter 的
Decoder不支持UseNumber()（即把数字全转成json.Number），标准库支持——这对需要高精度整数或区分 int/float 的场景是硬需求 - 若必须用 jsoniter 流式解析，记得调用
decoder.DisableStructFieldMangling(true)，否则遇到带下划线的字段名可能匹配失败（标准库默认忽略大小写和下划线）
Go 1.20+ 的 stdlib 已追平部分性能差距，尤其小结构体
Go 1.20 对 encoding/json 做了关键优化：引入了基于 unsafe 的字段偏移预计算、减少 reflect.Value 调用次数。在结构体字段少于 8 个、无嵌套、无指针的情况下，标准库与 jsoniter 的反序列化耗时差已缩至 10% 以内。
这意味着：如果你的 API 主要处理轻量 DTO（比如 type User { ID int `json:"id"` Name string `json:"name"` }），升级 Go 版本后，换 jsoniter 的收益可能不值得引入额外依赖和维护成本。
- 验证方式：用
go version确认是 1.20+，再跑benchstat对比前后结果，别凭印象决策 - 注意：标准库的优化不覆盖
interface{}场景，这种动态类型解析仍是 jsoniter 的优势区 - 容易被忽略的一点：jsoniter 的
Get方法（类似obj.Get("user").Get("profile").ToString()）在标准库中没有等价物，这是它独有的便利性，但性能代价高——每次Get都触发一次完整子树解析
