Go标准库encoding/json反射解析性能差，因encoding/json.(*decodeState).object、reflect.Value.Interface、reflect.Value.FieldByName三函数合计超25%即表明反射成瓶颈；FieldByName线性查找、不可内联、每次调用均堆分配，嵌套加深时开销指数增长。
Go标准库的encoding/json用反射做JSON解析，性能不好——不是“不够好”，而是它在高频、深嵌套、多字段场景下会成为明确瓶颈。pprof火焰图里只要encoding/json.(*decodeState).object、reflect.Value.Interface、reflect.Value.FieldByName三者合计占比超25%，基本就能断定是反射拖垮了反序列化。
为什么reflect.FieldByName在JSON反序列化里特别伤
结构体字段查找不是哈希查表，而是线性遍历+字符串比对。一个含100个字段的struct，平均要查50次才能定位到目标字段；每次FieldByName还触发一次堆分配（因为返回reflect.StructField需构造新值），且该函数无法被编译器内联。更糟的是，它在每次Unmarshal过程中对每个字段都调一次——哪怕你只用其中3个字段。
- 嵌套结构体每层都会重新触发一遍
FieldByName，深度为N时开销呈指数放大 - 字段名带下划线或大小写混用（如
user_name→UserName）会额外增加匹配尝试次数 - 使用
map[string]interface{}或interface{}字段时，整个路径退化为全反射，FieldByName调用频次翻倍
easyjson生成代码没提速？检查这四个硬条件
easyjson不是加了注释就自动生效，它依赖编译期静态绑定，漏掉任一条件就会fallback回encoding/json反射路径。
-
//easyjson:json必须独占一行，前后不能有空格或代码 - 结构体字段必须导出（首字母大写），否则生成的
UnmarshalJSON方法无法被外部调用 - 调用方必须显式走easyjson入口：
easyjson.Unmarshal(data, &v)或v.UnmarshalJSON(data)；若仍用json.Unmarshal，反射照旧 - 结构体里不能嵌套未生成easyjson的匿名struct或
interface{}，否则整条链路降级
尤其注意Gin/Echo框架：它们默认调json.Unmarshal，即使你的结构体已生成easyjson代码，也得手动替换绑定逻辑，或改用c.ShouldBindWith(&v, binding.JSON{...})指定解码器。
立即学习“go语言免费学习笔记（深入）”；
json.RawMessage不是“跳过解析”，而是延迟+风险解析
json.RawMessage只是把一段字节流原样存下来，并不省去任何解析开销——它在Unmarshal阶段仍要完整扫描、校验JSON语法、跳过空白和引号，只是不进一步拆成Go值。后续一旦调json.Unmarshal解它，等于做了两次完整解析。
- 正确用法：仅当该字段80%以上请求完全不访问时才用，比如
Data json.RawMessage `json:"data"` - 提取子字段时，优先用
gjson.GetBytes(data, "user.id")或fastjson直接切片，避免再进encoding/json路径 - 禁止把它塞进
map[string]interface{}再转结构体——这会激活完整的反射链路，白费功夫
别信“快10倍”的宣传，benchstat才是唯一裁判
所有第三方JSON库的性能数据都得自己压测验证。不同结构体形状、字段数量、是否含interface{}、Go版本都会导致结果剧烈波动。
- 测试命令固定为：
go test -bench=. -benchmem -count=10，用benchstat比对均值 - 关键指标只看三个：
ns/op（耗时）、B/op（分配字节数）、allocs/op（分配次数） - sonic在含
interface{}字段时性能掉约20%，而fastjson根本不支持该类型，得提前排除 - 务必用真实payload：比如API返回含30+字段的struct，或带500元素slice的数组，而非单字段小对象
最容易被忽略的是首次调用开销——jsoniter、sonic等库会在第一次Unmarshal时做反射缓存预热，后续才快；但微服务冷启动或低QPS场景下，这个“首次慢”可能就是P99毛刺来源。
