应使用 json.RawMessage 跳过不必要的解析，仅在需要时解构；结合 sync.Pool 复用结构体减少 GC；优先用 json.Decoder 处理流式或大 JSON；替换标准库为 easyjson 或 go-json 以规避反射开销。
用 json.RawMessage 跳过中间解析，只在真正需要时解构
当结构体中某些字段是嵌套 JSON（比如日志详情、配置片段、第三方回调 payload），但并非每次请求都需访问其内部字段时，直接声明为 json.RawMessage 可避免无谓的反序列化开销。Go 的 json.Unmarshal 遇到 json.RawMessage 会原样拷贝字节，不解析语法树、不分配子对象内存。
常见错误是统一用 map[string]interface{} 或深层 struct 接收，导致每次解析都做完整递归遍历和类型转换，性能损耗明显。
- 适用于：API 网关透传字段、审计日志中未定义 schema 的
metadata、兼容旧版可选扩展字段 - 注意：
json.RawMessage是[]byte别名，不可直接打印或比较，需先转string或再次json.Unmarshal - 若后续要多次读取同一
RawMessage，记得用copy或append保留副本——原数据随外层结构体被 GC 后可能失效
type Event struct {
ID string `json:"id"`
Timestamp int64 `json:"ts"`
Payload json.RawMessage `json:"payload"` // 不解析，零拷贝
}
var e Event
json.Unmarshal(data, &e)
// 仅当需要时才解析
var details map[string]string
json.Unmarshal(e.Payload, &details)
预分配结构体并复用 sync.Pool 减少 GC 压力
高频 JSON 解析场景（如微服务每秒数千请求）下，反复 new struct + 分配 map/slice 是 GC 主要来源。用 sync.Pool 缓存已分配的结构体指针，能显著降低堆分配频次和 STW 时间。
容易忽略的是：Pool 中对象必须保证“干净”，即不能残留上次使用的字段值，否则引发脏数据；且 Pool 本身不保证对象存活，不能依赖其长期持有。
立即学习“go语言免费学习笔记（深入）”；
- 不要把
sync.Pool用于含指针字段的结构体，除非你手动清空所有引用（比如重置为 nil） - 推荐只缓存纯值类型结构体，或在
New函数中显式初始化全部字段 - Pool 的 Get/ Put 成本很低，但滥用（如每次只用一次就 Put 回去）反而增加锁竞争
var eventPool = sync.Pool{
New: func() interface{} {
return &Event{Payload: make([]byte, 0, 512)}
},
}
func ParseEvent(data []byte) *Event {
e := eventPool.Get().(*Event)
e.ID = ""
e.Timestamp = 0
e.Payload = e.Payload[:0] // 清空 slice 底层数组引用
json.Unmarshal(data, e)
return e
}
// 使用后记得放回
defer eventPool.Put(e)
用 encoding/json 的 Decoder 替代 Unmarshal 处理流式或大体积 JSON
当输入是 io.Reader（如 HTTP body、文件、网络连接），或单次 JSON 数据超过几 MB 时，json.Unmarshal([]byte) 会强制一次性读入内存并复制，既浪费空间又触发大对象分配。而 json.NewDecoder 支持按需解析、边读边解，内存占用恒定。
典型误用是先把整个 HTTP body io.ReadAll 成 []byte 再传给 Unmarshal，尤其在处理上传配置或批量导入时极易 OOM。
-
Decoder默认启用缓冲，对小数据性能略低于Unmarshal，但差异在纳秒级，可忽略 - 支持
UseNumber()避免 float64 精度丢失，适合金融类整数 ID 字段 - 遇到非法 JSON 时，
Decoder的错误位置更精确（含偏移量），调试比Unmarshal更友好
dec := json.NewDecoder(r.Body)
dec.UseNumber() // 把数字转为 json.Number 类型，避免 float64 截断
var e Event
if err := dec.Decode(&e); err != nil {
// 错误信息含 offset，例如 "invalid character 'x' looking for beginning of value at offset 1234"
return err
}
避免反射式解析：用 easyjson 或 go-json 替代标准库
标准 encoding/json 重度依赖 reflect，字段查找、类型检查、方法调用全在运行时完成，CPU 消耗高。在 QPS 过万或延迟敏感服务中，这是最值得替换的一环。
注意：生成代码不是银弹。如果结构体频繁变更，维护 easyjson 生成的 _easyjson.go 文件会增加 CI 复杂度；而 go-json 无需代码生成，但要求 Go 1.18+ 且不支持所有 reflect 特性（如自定义 MarshalJSON 方法）。
-
easyjson：编译期生成MarshalJSON/UnmarshalJSON，性能提升 3–5×，但需额外 build 步骤 -
go-json：纯库，通过unsafe和内联优化绕过 reflect，性能接近 easyjson，接入成本低 - 二者均不兼容
json.RawMessage的部分行为（如嵌套 RawMessage 的深度拷贝逻辑），需实测验证
替换后，Unmarshal 调用不再走 reflect.Value，而是直接内存拷贝 + 条件跳转，热点函数 CPU 占比通常下降 40% 以上。
