反射慢的关键开销在于每次调用需重复进行类型解析、值拷贝、接口转换及线性字符串比对；缓存reflect.Type对应的字段索引映射可显著提升性能。
为什么反射一用就慢？关键开销在哪
反射慢不是错觉——reflect.ValueOf 每次调用都要做类型解析、值拷贝和接口转换；FieldByName 是线性遍历字段再字符串比对；MethodByName 还要查方法表。基准测试显示，反射创建结构体比 new() 慢 1.5 倍，而反射调用方法可能慢几十倍。
最常踩的坑是把反射塞进 HTTP handler 或数据库批量写入循环里，比如每次请求都 reflect.TypeOf(req) + parseTags()，CPU 全耗在重复解析上。
缓存类型信息，别让同一结构体反复“被反射”
结构体类型不变，它的字段名、tag、索引关系就不会变。把这些元数据在首次访问时解析好，存在 sync.Map 里，后续直接查表。
- 用
reflect.Type作 key，缓存map[string]int（字段名→索引）或自定义FieldInfo结构 - 避免缓存
reflect.Value实例本身（它绑定了具体值，不可复用），但可以缓存reflect.Type和预构建的reflect.StructField - 初始化阶段完成解析，比如在
init()函数或包变量中加载，而非每次调用时才触发
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]
}
能用类型断言，就别碰 reflect.Value.Kind()
当输入类型范围可控（比如只处理 string、int、User、Order），用 switch v := data.(type) 不仅快，还安全、可读、不逃逸。
立即学习“go语言免费学习笔记（深入）”；
-
reflect.TypeOf(data).Kind()要走接口类型擦除+运行时查找，而类型断言是编译期生成的跳转表 - 对已知结构体，直接
if u, ok := data.(User); ok { ... }，比反射取字段再赋值快一个数量级 - 仅对真正未知的泛型场景（如通用 JSON 解码器）才保留反射兜底路径
代码生成：把反射“编译掉”，性能接近手写
如果你的反射逻辑模式固定（比如所有带 json: tag 的结构体都要转 map），那就别让它活到运行时。
- 用
//go:generate配合gogenerate或自定义脚本，在go build前生成ToMap()、FromDB()等函数 - 主流方案如
ent、sqlboiler、protoc-gen-go全部走这条路——它们生成的代码里没有reflect，只有直白的字段访问 - 小项目也可手写简单模板：解析 AST 或结构体 tag，输出 .go 文件，
go:generate go run gen.go
最容易被忽略的是“缓存边界”：缓存不能无限制增长，sync.Map 虽线程安全，但若类型数爆炸（比如动态加载大量插件结构体），就得加 LRU 或按需清理；而代码生成看似重，实则把不确定性全转移到构建期，运行时反而最稳。
