Go反射序列化CPU高因热路径中reflect.ValueOf等操作动态查类型、分配对象、字符串比对；easyjson等生成静态代码可彻底规避反射，缓存reflect.Type而非reflect.Value，RPC应迁至gRPC+Protobuf。
Go里反射序列化（比如 encoding/json、encoding/gob、net/rpc 默认编解码）CPU 占用高，不是因为写得糙，而是反射本身在热路径上开销不可忽视——每次 reflect.ValueOf、FieldByIndex、Interface() 都要动态查类型、分配临时对象、走字符串比对或索引跳转。不绕开反射，只调参数或加缓存，效果有限。
为什么 json.Unmarshal 一压就 CPU 暴涨？
标准库反序列化时，每字段都要：解析 struct tag、查字段名字符串匹配、调 reflect.Value.Field(i)、再调 .Interface() 转成 interface{} —— 这些全是运行时开销。pprof 里常看到 encoding/json.(*decodeState).object 或 reflect.Value.Interface 占 40%+ CPU。
- 嵌套越深、字段越多，耗时线性增长；结构体有 20 个字段，和 2 个字段的开销差 5–8 倍
- 用
interface{}接收再断言，比直接解到具体结构体慢 3–5 倍，且无法做字段零值校验 - GC 频次随请求量陡增，
runtime.mallocgc成 top 函数，说明反射在疯狂造临时对象
禁用反射的实操路径：easyjson 生成静态方法
它把 json.Marshal/Unmarshal 编译期固化为纯函数，字段访问走偏移直取，彻底甩开 reflect 包。
- 结构体字段必须首字母大写，加注释
//easyjson:json（独占一行） - 执行
easyjson -all user.go，生成user_easyjson.go - 调用
user.MarshalJSON()替代json.Marshal(&user)，user.UnmarshalJSON()替代json.Unmarshal() - 不支持匿名字段自动展开；FIPS 合规环境需加
-no-unsafe参数
哪些地方不该缓存 reflect.Value？
很多人想用 sync.Map 缓存 reflect.Value 或 interface{} 当 key，结果白忙活——reflect.Value 是每次调用都新建的实例，没法复用；interface{} 作 map key 因底层含指针+类型双字段，相同类型不同变量也命中不了缓存。
立即学习“go语言免费学习笔记（深入）”；
- 该缓存的是
reflect.Type（全局唯一，地址恒定），key 用uintptr(unsafe.Pointer(reflect.TypeOf(x).UnsafePointer())) - 字段访问路径可缓存：比如结构体第 3 字段的
Offset，配合unsafe.Pointer直取，零反射 - 别池化
gob.Encoder实例——它内部的*bytes.Buffer每次 encode 都重置，复用无意义
RPC 场景下，换协议比调反射更有效
net/rpc 默认用 gob，但它把包路径（如 "main.User"）全塞进流里，解码时反复做字符串比对和类型重建；jsonrpc 看似简单，但靠 \n 分帧，TCP 粘包就 panic。光在反射层打补丁，治标不治本。
- 彻底迁移：用
grpc-go+protobuf，编译期生成代码，字段访问走偏移，零反射 - 兼容旧接口：改用
github.com/vmihailenco/msgpack/v5，加msgpack:"struct"标签 +msgpack.Register禁用反射 - 别碰
encoding/xml或手写ServerCodec——前者体积更大，后者要自己处理 header/body 分界、错误传播、连接生命周期，出错概率远高于收益
真正卡 CPU 的从来不是“要不要用反射”，而是“有没有在每毫秒都要跑几十次的热路径上，让反射成了必经之路”。绕不开时，至少把 reflect.Type 和字段偏移缓存住；能换协议，就别在 gob 或 json 的反射泥潭里调参。
