go中用reflect.valueof做类型转换比原生断言慢5–20倍，因运行时查表和安全检查开销大；仅当编译期完全未知类型且泛型无法覆盖时才必须用反射，如动态yaml解析、orm字段映射、测试深层比较等。
Go 中用 reflect.ValueOf 做类型转换（比如把 interface{} 转成 int）比原生类型断言或强制转换慢 5–20 倍，且会触发堆分配和逃逸分析失效——这不是“写法差异”，而是运行时查表 + 安全检查的必然开销。
什么时候必须用反射做类型转换
只有在「编译期完全无法预知输入类型」且「泛型无法覆盖」时才值得引入反射：
- 配置加载器：YAML 解析后是
map[interface{}]interface{}，字段名/嵌套深度/类型全动态，泛型无法统一处理 - 通用 ORM 字段映射：
struct{ Name string `gorm:"column:user_name"` }的 tag 解析和 SQL 绑定逻辑无法靠泛型展开 - 测试断言库深层比较：如
assert.Equal(t, got, want)需递归比对任意嵌套结构体字段，不能为每种组合写特化函数 - 序列化框架底层：JSON 反序列化时需根据 struct tag 自动解引用指针、跳过 omitempty 字段，这些行为无法静态推导
如果类型集合固定（比如只处理 []User、[]Order、[]Log），优先用泛型函数封装，而不是反射。
reflect.Value.Convert() 的实际性能陷阱
这个方法看似能替代类型断言，但代价远超预期：
- 每次调用都触发一次类型查表（
runtime.typesMap查找）和值拷贝，无法内联 - 目标类型必须是
reflect.Type实例，通常要先调用reflect.TypeOf(target)，又多一次查表 - 若源值是接口，
Convert()不会自动解包底层值，容易误传interface{}类型本身而非其内容 - 不支持跨类转换（如
int→string），只能转兼容类型（int32↔int64）
示例：把 interface{} 转 int64，原生写法只需 v.(int64) 或 v.(fmt.Stringer) 断言；用反射则要：
val := reflect.ValueOf(v)
if val.Kind() == reflect.Int64 {
result := val.Int()
}
这比断言多出至少 3 次函数调用和一次堆分配。
泛型能替代反射的常见误判场景
很多人以为“结构体字段名不同”就必须用反射，其实泛型配合约束（constraints）已能覆盖大部分情况：
- 日志字段提取：用
type Loggable interface{ GetID() int; GetName() string }+ 泛型函数，比反射遍历字段快 10 倍以上 - 简单配置绑定：定义
type Config[T any] struct{ Data T }，再用json.Unmarshal直接进泛型字段，无需反射中转 - 容器类型转换：
func ToSlice[T, U any](src []T, conv func(T) U) []U完全避免反射 - 错误包装：用
type WrapErr[T error] struct{ Err T; Msg string }替代反射构建错误链
真正需要反射的，是那些连「字段存在与否」都无法静态声明的场景，比如 ORM 的 SELECT * FROM ? 动态列映射。
最易被忽略的点：反射转换一旦进入 hot path（如 HTTP handler 内部循环、高频 ticker 回调），即使单次只慢 50ns，累积起来也会吃掉可观 CPU。缓存 reflect.Type 只能缓解查表，无法消除值拷贝和逃逸——这点在压测时才暴露得最清楚。
