reflect.TypeOf 和 reflect.ValueOf 在 interface{} 上反复调用性能最差，因每次需解包、查表、分配对象；FieldByName 是最大瓶颈，应预建字段索引映射；必须检查 IsValid 和 CanSet 避免 panic；缓存元数据宜用只读 map 而非 sync.Map。
reflect.TypeOf 和 reflect.ValueOf 在 interface{} 上反复调用最伤性能
空接口 interface{} 本身不带类型信息，每次调用 reflect.TypeOf(x) 或 reflect.ValueOf(x) 都要重新做接口解包、查类型表、分配 reflect.Type 和 reflect.Value 对象——这三步全是运行时开销。实测在热路径中单次调用比直接类型断言慢 5–10 倍。
常见错误写法：
func process(items []interface{}) {
for _, v := range items {
t := reflect.TypeOf(v) // 每次都重解析
val := reflect.ValueOf(v) // 每次都新建 reflect.Value
// …
}
}
正确做法是提前缓存或改用类型断言：
- 若输入类型有限（如只可能是
string、int、User），直接用switch v := x.(type) - 若必须泛化处理，把
reflect.TypeOf(v)提到循环外，或按类型缓存元数据 - 绝不把
reflect.ValueOf放在高频循环里，尤其不能对每个interface{}元素都调一次
FieldByName 是 interface{} + 反射组合里的最大瓶颈
当你从 interface{} 解出一个 struct 后再调 val.FieldByName("ID")，实际发生了两层开销：第一层是接口到反射值的转换，第二层是字段名线性遍历。20 字段的 struct 就要比较 20 次字符串，无法内联、无法编译期优化。
立即学习“go语言免费学习笔记（深入）”；
绕过方式很明确：
- 用
reflect.Type.NumField()预扫描一次，构建map[string]int缓存字段索引，后续用val.Field(idx) - 字段名固定且已知时，硬编码索引，比如
val.Field(0).String()，跳过所有字符串匹配 - 缓存 key 推荐用
uintptr(unsafe.Pointer(t))，而不是t.String()—— 后者对匿名 struct 失效，且 vendoring 下可能冲突
CanSet / IsValid 忘检查，panic 比性能问题来得更快
从 interface{} 过来的值，经过 reflect.ValueOf 后，IsValid() 不一定为 true（比如传了 nil 接口），CanSet() 更大概率是 false（因为没传指针）。漏掉任一判断，运行时就 panic。
典型错误场景：
- 传入 struct 值而非指针 →
reflect.ValueOf(s).FieldByName("Name").SetString("x")直接 panic - 传入 nil 接口 →
reflect.ValueOf(nil).Interface()崩溃 - 字段未导出 →
CanInterface()返回 false，但代码仍强行转成interface{}导致静默 nil
安全写法必须带前置判断：
v := reflect.ValueOf(x)
if !v.IsValid() { return }
if v.Kind() == reflect.Ptr { v = v.Elem() }
if !v.CanAddr() || !v.CanSet() { return }
// …
缓存策略选错，反而拖慢读多写少场景
很多人一上来就用 sync.Map 存字段映射，结果发现比普通 map + sync.RWMutex 还慢。原因很简单：sync.Map 的原子操作在纯读场景下开销更大，而反射元数据一旦生成基本不更新。
更合理的做法：
- 初始化阶段用普通
map[reflect.Type]fieldInfo构建缓存，完成后转为只读 - 如果真需要并发写（如动态加载新类型），用
sync.Once+ 指针替换，避免锁竞争 - 绝对不要缓存
reflect.Value实例——它绑定了具体值，不可复用，且无法作 map key
真正难处理的是字段 tag 解析和结构体布局变化：tag 解析必须预热，而一旦 struct 加字段或改顺序，缓存的字段索引就失效。这种耦合决定了——反射不是银弹，该用 go:generate 的地方，别硬扛。
