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 倍。
