reflect.ValueOf 和 reflect.Value.Interface() 在热路径中性能极差，因触发堆分配、类型检查和查表三重开销，实测比纯结构体访问慢60倍以上。
reflect.ValueOf 和 reflect.Value.Interface() 为什么在热路径里要命
这两个函数是反射性能开销最直接的来源，不是“慢一点”，而是触发堆分配 + 类型安全检查 + 查表三重惩罚。实测对一个 8 字段 struct 做字段遍历，纯结构体访问约 3ns，用 reflect.ValueOf + FieldByName + Interface() 平均耗时超 180ns，差 60 倍以上。
-
reflect.ValueOf(x)每次都重新解析类型系统，无法复用已知信息 -
v.Interface()必须做类型断言、逃逸分析重判、堆上分配新接口值，哪怕 x 是栈上小整数 - HTTP 中间件里对每个请求体做
reflect.ValueOf(req.Body)解析，p99 延迟可能跳升 1ms 以上（取决于调用频次）
MethodByName 调用前必须验证三件事
看似调用成功，Call() 才 panic，是因为 MethodByName 返回的是零值 reflect.Value，不报错但 .IsValid() 为 false。线上定位极难，堆栈里看不到方法名。
- 先检查
!method.IsValid()，否则Call()直接 crash - 接收者类型必须匹配：用
MyStruct{}去查(*MyStruct).Save方法，IsValid()就是 false - 参数列表必须严格一致：
int不能传int64，哪怕值相等，Call()也 panic - 无参也要传
[]reflect.Value{}，少写括号或写成[]reflect.Value(nil)都会 runtime panic
缓存 Type 比缓存 Value 更值得优先做
reflect.Type 是只读元数据，可全局复用；而 reflect.Value 绑定具体实例，每次调用 reflect.ValueOf(x) 都新建对象、触发逃逸。ORM 字段映射、日志 dump 等重复操作场景，缓存 Type 能省掉 70%+ 反射开销。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：
typeCache[reflect.TypeOf(MyStruct{}).Name()] = reflect.TypeOf(MyStruct{}) - 错误做法：把
reflect.ValueOf(instance)存进 map——它带实例状态，无法复用，还导致内存泄漏 - 字段遍历逻辑应基于缓存的
Type构建一次fieldCache，后续只用v.Field(i)，避免反复FieldByName
reflect.DeepEqual 在循环里等于 OOM 加速器
它不做短路判断，也不区分类型层级，一上来就递归展开所有字段。基准测试显示比手写比较慢近 40 倍，分钟级任务中反复调用极易引发 GC 抖动。
立即学习“go语言免费学习笔记（深入）”；
- 高频路径（如日志聚合、指标计算）绝对禁用
reflect.DeepEqual - 固定结构体优先手写
==，哪怕多几行代码 - 泛化需求用
jsoniter.ConfigFastest.Equal()这类预生成比较器，而非运行时反射 - 真需动态比较，先用
v.Kind()快速排除类型不匹配，避免进深层递归
真正棘手的不是“能不能用反射”，而是“用了之后是否意识到它悄悄把栈变量拖去堆上、把编译期确定的事拖到运行时查表”。越靠近请求入口、越频繁执行的代码，越该把反射挡在边界之外。
