Go反射序列化慢因热路径反复执行编译期可确定操作，用easyjson生成无反射MarshalJSON/UnmarshalJSON可提升3–5倍吞吐、减少90%+GC；需加//easyjson:json注释、导出字段、完整json标签，运行easyjson -all生成代码，Gin/Echo自动调用，禁用interface{}和未生成匿名struct。
Go 反射序列化慢，不是因为写法错，而是你让它在热路径上反复做本该编译期完成的事——字段查找、标签解析、接口转换全堆在运行时。绕过它，性能能提 3–5 倍，GC 分配减少 90%+。
用 easyjson 生成无反射 MarshalJSON/UnmarshalJSON
这是最稳、改动最小的提速方案：不换框架、不改调用方式，只让结构体自己“长出”序列化能力。
-
//easyjson:json注释必须独占一行，且紧贴结构体定义上方；字段必须导出（首字母大写），jsontag 要完整 - 运行
easyjson -all models.go，生成models_easyjson.go；该文件里全是strconv.AppendInt、unsafe.String这类直写逻辑，零reflect.Value - Gin/Echo 的
c.ShouldBindJSON(&v)会自动 fallback 到v.UnmarshalJSON()，只要你的结构体实现了该方法，就生效 - 别在结构体里嵌套未生成的匿名 struct，也别用
interface{}接收，否则 easyjson 完全不触发
缓存 reflect.Type 和预建字段索引，别缓存 reflect.Value
同一类型的 reflect.Type 在整个进程生命周期内地址恒定，是安全的缓存 key；而 reflect.Value 每次都新分配，缓存它等于白干。
- key 推荐用
uintptr(unsafe.Pointer(t))，比t.String()快、无字符串分配、对匿名 struct 也有效 - 缓存内容建议是预计算的
fieldInfo切片：type fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，而不是裸的[]reflect.StructField -
FieldByName是 O(n) 字符串比对，100 字段就要比 100 次；换成Field(i)+ 索引 map[string]int 查表，直接变 O(1) - 别用
sync.Map存字段映射——读多写少场景下，它的原子操作比map+sync.RWMutex更重
热路径彻底甩开反射：用 unsafe.Offsetof 生成 getter/setter 闭包
这不是通用优化，而是针对明确瓶颈点的手术刀式处理，比如高频 DB 模型序列化或日志字段提取。
立即学习“go语言免费学习笔记（深入）”；
- 字段偏移一旦算出，
offset := unsafe.Offsetof(User{}.Name)就是常量；闭包封装成func(u *User) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + offset)) } - 必须传指针，且确保类型不会被 GC 移动（命名类型安全，但若从
interface{}转来，需先reflect.ValueOf(v).UnsafeAddr()） - 字段顺序变动、加字段、甚至启用
//go:build !no_unsafe都会让闭包失效；CI 中要加检查：go vet -tags=no_unsafe ./... - ent 或 sqlc 生成的代码底层就是这么干的——它们不提供“任意 struct → 任意表”，而是用约束换掉反射
别在 ORM 层再包一层“泛型 repository”
ent/sqlc 已经把反射干掉了，你再套一层 interface{} + reflect 通用 wrapper，等于亲手把性能拉回起点。
- ent 的
client.User.Create().SetEmail(...).Save(ctx)是纯方法链，零反射；sqlc的db.Queries.CreateUser(ctx, arg)参数直绑，不经过interface{} - 所谓“统一 repository 接口”听起来优雅，实际引入额外接口逃逸、反射调用、参数包装三层开销
- 如果真要抽象，用代码生成（
go:generate）产出类型固定的方法，而不是运行时靠反射拼接 - 字段增删后，
go generate必须进 CI 流程：go generate && git diff --quiet || (echo "go:generate out of date" && exit 1)
真正卡住性能的从来不是反射本身，而是你在不该用的地方反复调用它——比如每次 HTTP 请求都重新 reflect.TypeOf 同一个结构体，或者在 for 循环里 FieldByName 查同一个字段名。这些地方，缓存或生成才是正解；而更深层的问题，比如是否真需要“通用 ORM”，往往比怎么优化反射更重要。
