Go反射性能差，应缓存Type和字段索引、用类型断言替代Kind判断、编译期生成代码（如easyjson）、热路径彻底剔除反射，并依据稳定性权衡优化投入。
Go 反射确实慢——方法调用比直接调用慢数十倍，字段查找（FieldByName）是线性扫描，Value.Interface() 和 Value.Set() 还会触发逃逸和内存分配。这不是“能用就行”的问题，而是高频场景下 CPU 和 GC 明显吃紧的现实瓶颈。
缓存 reflect.Type 和字段索引，别每次重解析
重复调用 reflect.TypeOf 或遍历结构体字段是最常见的性能浪费。同一类型解析一次就够了，后续查表即可。
- 用
sync.Map缓存reflect.Type → map[string]int（字段名到索引映射），避免每次FieldByName都遍历所有字段 - 初始化时就构建好字段信息（是否导出、tag 值、类型等），运行时只做
value.Field(i)这种 O(1) 操作 - 别缓存
reflect.Value实例本身去跨 goroutine 复用——它包含运行时状态，不安全；缓存Type和索引才是正解
用类型断言或 switch x := v.(type) 替代 reflect.Value.Kind()
当你知道输入只可能是几个固定类型（比如配置解析支持 string/int/bool），反射就是杀鸡用牛刀。
-
v, ok := data.(User)比reflect.TypeOf(data).Name() == "User"快一个数量级，且编译期可优化 -
switch x := data.(type)能批量覆盖常见类型，未知类型再 fallback 到反射，既安全又高效 - ORM 参数绑定、API 请求体校验这类场景，80% 的请求走的是已知结构体，没必要全量反射
生成代码替代运行时反射：easyjson、sqlboiler、自定义 //go:generate
如果结构体定义稳定，就别在运行时猜字段了。把反射逻辑移到编译期，生成的代码性能接近手写。
立即学习“go语言免费学习笔记（深入）”；
- 对 JSON 场景：加
//easyjson:json注释 + 运行easyjson -all models.go，生成无反射的MarshalJSON，吞吐提升 2–5 倍 - 对数据库映射：用
sqlboiler或ent生成User.FromRows()，字段访问全是直接内存偏移，零reflect开销 - 自定义生成：用
go:generate扫描 struct tag，输出ToMap()或Validate()函数，控制力更强
热路径里彻底剔除反射，哪怕多写几行代码
API 请求处理、消息编解码、循环内字段赋值——这些地方每微秒都算数。反射在这里不是“不够快”，而是“根本不该出现”。
- 不要在 HTTP handler 里反复
json.Unmarshal到interface{}再反射取字段；定义具体结构体，让标准库或 easyjson 直接解到字段 - 避免在 for 循环里调用
MethodByName；提前缓存好reflect.Method或干脆用函数指针列表 - 第三方库（如
mapstructure）默认带反射，启用WeaklyTypedInput或缓存 schema 后再用，否则等于白优化
真正难的不是“怎么缓存”或“怎么生成代码”，而是判断哪部分值得投入——有些结构体一年变三次，硬上代码生成反而拖慢迭代；而核心模型稳定半年以上，省下的 CPU 时间和 GC 压力，很快就能回本。优化前先跑 go test -bench=. 和 go tool pprof，看清楚火焰图里到底烧在哪。
