Go标准库encoding/json在高并发等场景成性能瓶颈，主因是反射和临时内存分配；优化方案包括用json.RawMessage跳过解析、easyjson生成静态方法绕过反射、复用json.Encoder和sync.Pool缓冲区。
Go 标准库 encoding/json 在多数场景下够用，但一旦进入高并发 API、实时数据管道或资源受限服务，它就成了性能瓶颈——不是功能不行，是反射和临时内存分配拖慢了整体吞吐。直接换库或改结构体前，先确认你面对的是哪类问题。
为什么 json.Unmarshal 会卡住 CPU？
标准库反序列化时每轮都走 reflect.Value.Interface 和字段标签解析，结构体字段越多、嵌套越深，开销越线性增长。pprof 中常见 encoding/json.(*decodeState).object 占比超 40%，GC 频次也随请求量陡增。
- 典型现象：QPS 上万时，
runtime.mallocgc调用次数飙升，P99 延迟毛刺明显 - 不是所有字段都需要解析——比如 Webhook payload 里只关心
event.type和data.id，却对整个 JSON 调用json.Unmarshal -
interface{}接收再类型断言，比直接解到结构体慢 3–5 倍，且无法做字段级零值校验
用 json.RawMessage 跳过中间解析
适用于“主结构稳定、子内容动态”的场景，比如消息路由、事件分发。它把某段 JSON 字节流原样缓存，不触发解析，后续按需提取。
- 定义结构体时，把不确定的字段声明为
json.RawMessage类型，例如：Data json.RawMessage `json:"data"` - 后续用
gjson.GetBytes(user.Data, "items.#.price")直接取值，无内存分配、不校验 JSON 合法性（需前置json.Valid） - 避免误用：若同一段
RawMessage被反复解析 >2 次，不如一次性解到精简结构体，否则等于把延迟解析变成重复解析
easyjson 生成静态方法绕过反射
它在编译期为每个结构体生成专用的 MarshalJSON/UnmarshalJSON，彻底消除运行时反射，实测吞吐提升 3–10 倍，GC 分配减少 80%+。
立即学习“go语言免费学习笔记（深入）”；
- 结构体需带
json:标签，且字段首字母大写；加注释//easyjson:json（独占一行） - 执行
easyjson -all user.go，生成user_easyjson.go，调用user.MarshalJSON()替代json.Marshal(&user) - 注意：不支持匿名字段自动展开；FIPS 合规环境需加
-no-unsafe参数禁用字符串零拷贝
复用 json.Encoder 和缓冲区降低 GC 压力
高频 HTTP handler 或日志批量写入中，每次新建 *bytes.Buffer 或 json.Encoder 会快速触发 GC。对象池是更稳的选择。
- 声明全局
var bufferPool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }} - handler 内：从池取
buf := bufferPool.Get().(*bytes.Buffer)，用完buf.Reset()后归还，不直接buf = nil - 对固定结构体，复用
jsoniter.ConfigFastest.NewEncoder(buf)实例，比每次都 new 快 20%+
真正难的不是选哪个库，而是判断哪些字段必须强校验、哪些可以跳过、哪些该提前 json.Valid 过滤。盲目上 easyjson 却忽略业务语义，反而让错误更难定位。
