Go反射显著拖慢程序，高频路径中reflect.FieldByName比直接访问慢20倍，方法调用慢40倍；应缓存reflect.Type及字段索引，预提取标签与偏移，避免重复解析和字符串比对。
Go反射会显著拖慢程序，尤其在高频路径（如API解码、ORM字段映射、序列化）中，一次 reflect.FieldByName 调用可能比直接字段访问慢20倍，反射方法调用甚至可达直接调用的40倍。这不是理论值——基准测试显示，仅是创建一个 reflect.Value 就比直接构造多出约50%耗时和32 B内存分配。
缓存 reflect.Type 和字段索引，别每次都重解析
每次调用 reflect.TypeOf 或遍历 t.NumField() 都要重新扫描结构体元数据，属于纯CPU浪费。真实场景中（比如JSON库首次解析某个结构体），你只需要做一次；后续所有同类型对象都该复用结果。
- 用
sync.Map缓存reflect.Type → map[string]int（字段名到索引映射），避免FieldByName的线性字符串比对 - 初始化阶段就预提取字段标签（如
json:"name"）、是否导出、内存偏移等，运行时只查表 - 不要缓存
reflect.Value本身（它包含值拷贝，可能逃逸），但可缓存其构建逻辑或字段reflect.StructField切片
var fieldIndexCache sync.Map // map[reflect.Type]map[string]int
func getFieldIndex(t reflect.Type, name string) int {
if cached, ok := fieldIndexCache.Load(t); ok {
return cached.(map[string]int)[name]
}
indexes := make(map[string]int)
for i := 0; i < t.NumField(); i++ {
indexes[t.Field(i).Name] = i
}
fieldIndexCache.Store(t, indexes)
return indexes[name]
}
用 Field(i) 替代 FieldByName，索引访问快一个数量级
FieldByName 内部是遍历所有字段并逐个比较字符串，O(n)；而 Field(i) 是直接数组寻址，O(1)。只要你在初始化阶段已知字段顺序（比如通过缓存或代码生成），就绝不要在热路径里用名字查。
- 字段顺序由源码定义顺序决定，稳定可靠（除非手动改结构体字段顺序）
- 配合缓存的索引映射，
v.Field(getFieldIndex(t, "Name"))可转为v.Field(cachedIndex) - 注意：若结构体含嵌入字段（anonymous struct），
NumField()和实际字段可见性需额外处理，别盲目硬编码索引
能不用反射，就别用；能用类型断言，就不走 reflect.Value.Kind()
当处理类型集合有限（如只支持 string、int、struct{}）时，用 switch x := data.(type) 比用反射判断 Kind() 快得多，且零内存分配、类型安全、编译期可检查。
- 反射适合“任意类型”的通用框架层（如
encoding/json），业务逻辑层几乎不需要 - 常见误用：为几个固定类型写一堆
if v.Kind() == reflect.String { ... }，其实一个switch就搞定 - 接口抽象更优：定义
type Marshaler interface { MarshalJSON() ([]byte, error) }，让具体类型自己实现，框架只调接口
switch x := data.(type) {
case string:
return json.Marshal(x)
case User:
return x.MarshalJSON() // 假设实现了接口
case map[string]interface{}:
return json.Marshal(x)
default:
return fmt.Errorf("unsupported type %T", x)
}
用 go generate + 模板生成类型专用代码，彻底消灭运行时反射
这是最彻底的优化——把反射逻辑从运行时搬到编译期。标准库 encoding/json 在 Go 1.19+ 已对常见类型（如 struct 字段少于8个）启用代码生成优化；你自己也能做到。
-
工具链推荐：
gofast（高性能序列化生成器）、ent（ORM）、自定义go:generate+text/template - 典型产出：每个结构体对应一个
func (u *User) ToMap() map[string]interface{}，字段访问全静态，无反射开销 - 代价是构建时间略增、代码体积稍大，但运行时性能接近原生，且 IDE 支持跳转/补全
最容易被忽略的一点：缓存不是万能的——sync.Map 自身有锁开销，如果类型特别多（比如每请求动态生成新 struct 类型），缓存反而成瓶颈；此时应优先考虑代码生成或限制反射使用范围。真正的高性能反射优化，从来不是“怎么缓更快”，而是“能不能不反射”。
