encoding/json.(*decodeState).object、reflect.Value.Interface、reflect.Value.FieldByName是火焰图中需重点盯住的三个最耗时函数，占比超25%即可判定反射拖慢反序列化。
pprof 火焰图里看哪几个函数最耗时
直接跑 go tool pprof，重点盯住这三块：encoding/json.(*decodeState).object、reflect.Value.Interface、reflect.Value.FieldByName。只要它们在火焰图顶部占超过 25%，基本就能断定是标准库反射拖慢了反序列化。
常见现象：
-
encoding/json.(*decodeState).object高占比 → 字段多或嵌套深，每次都要重新遍历结构体 -
reflect.Value.Interface频繁出现 → 反序列化过程中反复装箱/拆箱 interface{}，触发大量堆分配 -
reflect.Value.FieldByName持续升温 → 字段名查找走线性比对，100字段结构体平均要查50次，且无法内联
用 benchstat 对比不同 JSON 库的真实开销
别信文档里的“快 10 倍”，自己压测才靠谱。关键指标就三个：B/op（每次操作分配字节数）、allocs/op（每次分配次数）、ns/op（纳秒级耗时）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试数据必须贴近真实场景：比如 API 返回含 30+ 字段的 struct，或带 500 元素 slice 的 payload
- 用
go test -bench=.跑 10 轮取平均，加-benchmem抓内存数据 - 对比时固定 Go 版本（如 1.26.0），避免 runtime 变更干扰结果
- 特别注意
sonic在含interface{}字段时会掉约 20% 性能，而fastjson完全不支持该类型，得提前排除
检查 json.RawMessage 是否真跳过了解析
json.RawMessage 不是“免解析”，只是延迟解析——如果后续又调了 json.Unmarshal 解它，等于做了两次解析，反而更慢。
正确用法：
- 只在确定字段内容复杂、且 80% 请求都不访问它时才用，比如
Data json.RawMessage `json:"data"` - 后续提取子字段优先用
fastjson或gjson直接切片，避免再进encoding/json路径 - 别把它塞进 map[string]interface{} 再转结构体，那会激活反射链路，白费功夫
easyjson 生成代码后为什么没生效
easyjson 不是“写了注释就提速”，必须满足四个硬条件：
- 结构体字段必须导出（首字母大写），否则生成的
MarshalJSON方法无法被框架调用 -
//easyjson:json注释必须独占一行，前后不能有空格或代码 - 调用方必须走 easyjson 提供的入口，比如
easyjson.Marshal(v)或结构体自带的v.MarshalJSON()；若仍用json.Marshal(v)，反射照旧 - 结构体里不能嵌套未生成 easyjson 的匿名 struct 或 interface{}，否则 fallback 到标准库路径
最容易被忽略的是 Gin/Echo 这类框架的绑定逻辑：它们默认调 json.Unmarshal，除非你显式注册 easyjson 的解码器，或者让结构体实现 UnmarshalJSON 方法并确保它被调用。
