json-iterator vs sonic vs easyjson 性能对比测试

sonic在Go 1.20+下纯结构体编解码比json-iterator快1.2–1.8倍，但需sonic-gen生成代码且不支持interface{}；json-iterator更灵活，适合运行时类型不确定场景；easyjson因unsafe和泛型支持差已逐渐被淘汰。

json-iterator 和 sonic 的 benchmark 差异在哪

实测中，sonic 在 Go 1.20+ 下对纯结构体序列化/反序列化普遍比 json-iterator 快 1.2–1.8 倍，尤其在含嵌套 slice 或 map 的场景下优势更明显。但这个差距只在“无反射、已知 schema”的前提下成立——sonic 要求提前生成代码（sonic-gen），而 json-iterator 默认走运行时反射路径。

容易踩的坑：

• sonic 对 interface{} 或动态字段支持弱，遇到 map[string]interface{} 会 fallback 到标准库，性能骤降
• json-iterator.ConfigFroze() 必须显式调用才能关闭反射，否则和 encoding/json 差不多慢
• Go 1.21+ 中 sonic 的 UnsafeString 模式需手动开启，否则不启用零拷贝优化

easyjson 为什么在新项目里越来越少被选

easyjson 生成的代码依赖大量 unsafe 和底层字节操作，在 Go 1.20 后频繁触发 vet 检查警告，且与 go:build 约束、模块校验兼容性差。它不支持泛型结构体（如 type List[T any]），也不处理 json.RawMessage 的嵌套引用。

实操建议：

• 已有项目可继续用，但别新增 easyjson 生成逻辑
• 若必须用生成式方案，优先考虑 sonic-gen，它输出的是干净 Go 代码，无 unsafe，且支持泛型
• easyjson 的 MarshalJSON 方法签名和标准库不一致，混用时容易漏掉错误返回检查

真实服务压测中三者表现并不只看吞吐量

在 HTTP 服务中，JSON 编解码往往不是瓶颈，真正影响 P99 延迟的是内存分配和 GC 压力。实测发现：sonic 分配更少堆内存（尤其小 payload），json-iterator 在大 payload 下因缓冲复用策略更优，easyjson 因深度内联反而导致二进制体积膨胀 8–12%，影响冷启动和 cache miss。

关键参数差异：

• sonic：默认启用 DisableStructTag，忽略 json: tag，需手动打开
• json-iterator：ConfigCompatibleWithStandardLibrary 开启后才兼容 omitempty 行为
• easyjson：无 runtime 配置项，一切由生成时 -tags 决定，改配置就得重生成

什么时候该放弃 benchmark 数字选 json-iterator

当你的结构体字段名来自外部配置（比如用户自定义字段映射）、或需要运行时注册类型（如插件系统加载新 struct）、或必须支持 json.RawMessage 动态解析时，sonic 和 easyjson 都无法满足——它们都要求编译期完全已知类型。

这时 json-iterator 是唯一能兼顾灵活性与可控性能的选择，只要记得：

• 用 jsoniter.ConfigCompatibleWithStandardLibrary().Froze() 初始化
• 避免反复创建 jsoniter.API 实例，全局复用一个
• 对高频小对象，可配合 sync.Pool 复用 *jsoniter.Iterator

生成式方案省下的 CPU 时间，有时会被调试难度和维护成本吃掉；尤其是字段名拼写错误、tag 写错、或升级 Go 版本后生成失败这类问题，排查起来比调优慢 10 倍。