Go标准库encoding/json性能瓶颈源于反射、动态类型检查和内存分配；jsoniter通过编译期优化和缓存提升2–5倍吞吐，easyjson生成静态代码再提速30%–50%。
Go 标准库 encoding/json 默认性能不差，但高频或大数据量场景下，序列化常成瓶颈——直接换用 jsoniter 或 easyjson 能提升 2–5 倍吞吐，且多数情况只需改导入和初始化，无需重写结构体。
为什么标准 json.Marshal 慢？
它依赖反射遍历字段、动态类型检查、字符串拼接和内存反复分配。尤其当结构体嵌套深、字段多、含指针或接口时，开销明显上升；同时，每次调用都重新解析 struct tag，无法复用元信息。
常见现象：cpu profile 显示 reflect.Value.Interface 或 encoding/json.(*encodeState).marshal 占比高；压测中 QPS 上不去，pprof 显示大量小对象分配（runtime.mallocgc 高频）。
用 jsoniter 替代，零侵入切换
它兼容标准库 API，仅需替换导入和初始化，即可获得编译期优化 + 缓存机制带来的性能提升。对已用 json.Marshal/json.Unmarshal 的项目，改造成本极低。
立即学习“go语言免费学习笔记（深入）”；
- 将
import "encoding/json"改为import jsoniter "github.com/json-iterator/go" - 全局替换函数调用：把
json.Marshal→jsoniter.ConfigCompatibleWithStandardLibrary.Marshal（或提前定义别名var json = jsoniter.ConfigCompatibleWithStandardLibrary） - 若需更高性能（放弃部分兼容性），启用
jsoniter.Config{StrictFloat64: true}并禁用反射 fallback（通过RegisterTypeEncoder手动注册热点类型） - 注意：
jsoniter默认不支持time.Time的自定义 layout，需显式注册编码器，否则仍走反射路径
生成静态代码：用 easyjson 彻底绕过反射
它在构建时（go:generate）为每个 struct 生成专用的 MarshalJSON/UnmarshalJSON 方法，完全消除运行时反射，序列化速度通常比 jsoniter 再快 30%–50%，但需接受额外的 build 步骤和代码膨胀。
使用前提：结构体字段稳定、不频繁变更；能接受生成文件（如 xxx_easyjson.go）进入代码库。
- 安装：
go install github.com/mailru/easyjson/...@latest - 在目标 struct 上方加注释：
//easyjson:json - 执行：
easyjson -all xxx.go，生成对应xxx_easyjson.go - 调用时仍用原方法名（如
user.MarshalJSON()），但底层是生成的无反射代码 - 注意：嵌套结构体也需各自标注
//easyjson:json，否则回退到标准库逻辑
其他关键优化点（常被忽略）
再快的库也救不了错误的数据结构设计或滥用模式。以下三点不改代码逻辑，但影响极大：
- 避免在 hot path 中对同一对象反复
json.Marshal：缓存结果（[]byte）比重复序列化便宜得多，尤其响应内容固定时（如 API 文档、配置模板） - 慎用
interface{}和map[string]interface{}：它们强制走最慢的反射分支；优先定义具体 struct，或用json.RawMessage延迟解析 - 关闭
json.Encoder的SetEscapeHTML(true)（默认开启）：若输出不直面 HTML 页面（如内部 RPC、日志上报），设为false可省去字符转义开销，提速约 10%–15%
真正卡顿的往往不是“选哪个库”，而是没意识到 json.Marshal 被调用了多少次、传入的是什么类型、是否在循环里反复构造 map 或 interface{}。
