标准库json.Marshal在高频或结构复杂场景下性能差，主因是每次调用均需反射查字段、动态类型判断及小对象分配；优化应优先采用easyjson预生成无反射代码（吞吐提升2–5倍、GC减少90%+）或jsoniter配对启用ConfigFastest，同时排查上游数据构造瓶颈。
标准库 json.Marshal 在高频或结构复杂场景下性能差，不是写法问题，而是反射、类型判断和小对象分配的固有开销；换库或生成代码前，先确认瓶颈真在序列化本身——很多“慢”实际出在上游数据构造环节。
为什么 json.Marshal 在微服务里特别拖后腿
微服务接口通常结构稳定、调用量大，但 encoding/json 每次调用都要走反射查字段、动态判断类型、拼接键值对。QPS 上万时，reflect.Value.Interface 和 encoding/json.(*encodeState).marshal 占 CPU 高峰是常态。同时每个请求新建 []byte 和临时 map，GC 压力飙升，P99 延迟跳变。
- 结构体字段超过 10 个，或嵌套深度 ≥3，反射遍历成本指数上升
- 传入
map[string]interface{}或interface{}类型，强制走最通用（也最慢）路径 - 字段含指针或
json.RawMessage，每次都要做nil检查和边界判断 -
pprof显示reflect.Value.Interface占 CPU >30%，基本可判定为序列化瓶颈
用 easyjson 生成无反射代码（最稳的提速点）
它不 runtime 查字段，而是在构建阶段把 MarshalJSON 方法硬编码进源码，实测吞吐提升 2–5 倍，GC 分配减少 90%+。但生效有明确前提：
-
//easyjson:json必须独占一行，写在结构体定义正上方 - 结构体字段必须导出（首字母大写），且带明确
json:标签，如ID int `json:"id"` - 运行
easyjson -all user.go，生成user_easyjson.go；该文件必须和源码一起编译，漏掉就退化回标准库 - 调用时改用
u.MarshalJSON()或easyjson.Marshal(&u)，别再用json.Marshal(&u) - 不支持
interface{}字段，遇到会 panic；需提前 flatten，比如把map[string]interface{}拆成具体字段
用 jsoniter 零修改接入但必须配对启用
API 完全兼容标准库，适合快速验证效果，但默认配置没开加速，白换等于没换：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
立即学习“go语言免费学习笔记（深入）”；
- 导入替换：
import jsoniter "github.com/json-iterator/go"，再用jsoniter.ConfigCompatibleWithStandardLibrary.Marshal - 必须全局复用一个
jsoniter.API实例，别在 hot path 里反复调用jsoniter.Config{}.Froze() - 要提速得显式绑定类型：
jsoniter.RegisterTypeEncoder("User", &userEncoder{})，否则仍走反射 - 可信数据场景可启用
Unsafe=true，跳过部分边界检查，提速 20–40%，但禁止用于用户直传 JSON -
EscapeHTML: false能省掉 HTML 实体转义（如<→\u003c），提升 5%–10% 吞吐
别忽略上游数据构造这个真瓶颈
很多服务换了 sonic 或 easyjson 后 QPS 没涨，问题不在 Marshal 函数本身：
- 避免在循环里拼
map[string]interface{}，改用预定义 struct +omitempty -
json.RawMessage不优化拷贝，大量透传子 JSON 时，直接用[]byte拼接更省 - 高频接口中，复用
bytes.Buffer或sync.Pool管理切片，防止短生命周期[]byte逃逸 - 时间字段默认输出纳秒时间戳（
sonic）、或 HTML 转义（jsoniter），和前端预期不符时，得手动注册 encoder
真正耗时的往往不是最后一步——上游拼 map、构造嵌套结构体、反复 new 小对象，这些才是藏得最深的性能黑洞。
