reflect.TypeOf 和 reflect.ValueOf 每次调用均引发运行时查表、装箱及对象构造三重开销，FieldByName/MethodByName 为 O(n) 线性查找且返回新 reflect.Value 导致堆分配，Call 方法因参数转换、类型检查、反射分发和返回值拆包而慢50–100倍；手动缓存 Type 和字段/方法索引可将性能提升至纳秒级。
reflect.ValueOf 和 reflect.TypeOf 每次调用都触发三重开销
这不是“取个类型”那么简单，而是每次调用都会实际走一遍运行时查表 + 装箱 + 构造对象的完整路径：
-
reflect.TypeOf会查全局类型哈希表runtime.types，涉及指针跳转和哈希计算，无法内联 -
reflect.ValueOf必须先把原始值装箱进interface{}，对结构体或 slice 触发堆分配（哪怕只是临时用） - 构造出的
reflect.Type或reflect.Value内部含额外标志位、指针、类型缓存字段，本身就有内存开销
实测：对一个 8 字段 struct 调用一次 reflect.ValueOf，平均耗时 120–180ns；而直接访问字段只要 3ns。差的是量级，不是常数。
FieldByName / MethodByName 查找走线性匹配而非哈希
Go 的反射字段/方法查找不是 O(1)，而是 O(n) 遍历结构体字段数组或方法表：
-
v.FieldByName("Name")本质是遍历v.Type().NumField()个字段，逐个比对名字字符串 - 如果字段名拼错、大小写不对、或字段未导出，它不会提前退出，而是跑完全部字段才返回零值
-
v.MethodByName("Do")同理，需遍历所有导出方法，且只匹配首字母大写的名称
更隐蔽的问题是：这些函数返回新 reflect.Value，又触发一次堆分配 —— 连续调用 FieldByName 两次，就可能产生两个逃逸对象。
立即学习“go语言免费学习笔记（深入）”；
Call 方法调用比直接调用慢 50–100 倍
reflect.Value.Call 是反射里最重的操作，慢在四层叠加：
- 参数要从
[]interface{}转成[]reflect.Value，每个元素都得reflect.ValueOf一遍 - 调用前做类型检查、可调用性验证（
v.CanCall()）、参数个数/类型对齐 - 实际执行走的是反射封装的分发逻辑，不是直接 CALL 指令，中间有边界检查和返回值打包
- 返回值再通过
.Interface()拆包，又一次堆分配 + 类型断言
常见误用：HTTP 中间件里每请求都 reqVal.MethodByName("Header").Call(nil) —— profile 里立刻亮成红色热点。
缓存 Type 和字段索引能降到纳秒级，但必须手动做
类型元数据是只读、全局唯一的，重复解析纯属浪费。但 Go 不会自动帮你缓存，得自己落地：
- 首次用
reflect.TypeOf(T{})获取reflect.Type，存为全局变量或 sync.Map - 字段名转索引用
t.FieldByName("Name")一次，记下StructField.Index（如[0]），后续直接v.FieldByIndex([0]) - 方法也一样：
t.MethodByName("Do")拿到Method.Func，缓存为func(...interface{}) []interface{}封装器
注意：reflect.Value 不能缓存（它绑定了具体实例），只能缓存 Type 和字段/方法的静态描述。漏掉这层区分，缓存就白做了。
