reflect.Value.Call比直接调用慢50–100倍是实测值，空方法耗时1.2 ns vs 80–120 ns；根本原因在于绕过编译器优化、重建调用栈、校验参数、分配切片及额外接口转换。
reflect.Value.Call 比直接调用慢 50–100 倍是实测值，不是理论估算
这个量级差异在 Go 1.22+ 依然成立。一个空方法 func() {} 直接调用耗时约 1.2 ns，而用 reflect.Value.Call 调用稳定在 80–120 ns；带两个 int 参数的方法，慢约 35 倍；若参数含 interface{} 或嵌套结构体，慢 60 倍以上。
根本原因不是“写得不够好”，而是反射调用必须绕过所有编译器优化：内联失效、逃逸分析不准、CPU 分支预测失败，且每次都要重建调用栈——查方法表、校验导出性/可寻址性、转换参数格式、触发 runtime.call 汇编入口。
- 校验阶段只占总开销的 15–20%，缓存
MethodByName结果只能省这部分 -
Call本身无法跳过，每次都会分配临时[]reflect.Value参数切片，高频调用会推高 GC 压力 - 返回值仍是
reflect.Value，若需取结果还得再调一次Interface()，又是一次接口转换和堆分配
FieldByName 访问字段比点号访问慢 30–60 倍
写 user.Name 是编译期确定内存偏移，CPU 一条指令完成；而 reflect.ValueOf(user).FieldByName("Name") 要走完整运行时路径：查类型描述符表 → 遍历字段列表字符串匹配 → 检查导出性 → 构造新 reflect.Value → 类型检查 → 搬运字段值。
这个过程涉及多次函数调用、边界检查、堆分配（尤其当 user 是大结构体或含 slice 时），profile 里常表现为 runtime.mallocgc 和 reflect.(*structType).FieldByName 双高。
立即学习“go语言免费学习笔记（深入）”；
- 字段名匹配是线性遍历，不依赖哈希，字段越多越慢
- 即使结构体字段顺序固定，也无法跳过字符串比较环节
- 缓存
reflect.StructField或字段索引（Field(i)）可将后续访问压到纳秒级，但首次解析开销不变
reflect.TypeOf / reflect.ValueOf 一调就逃逸，别在热路径上反复用
每次调用 reflect.TypeOf(x) 或 reflect.ValueOf(x) 都会：查全局类型哈希表 runtime.types、把 x 装箱进 interface{}（触发堆分配）、构造新 reflect.Type 或 reflect.Value 实例。
对大结构体或 slice，装箱成本尤其高；编译器通常无法证明这些 reflect.Value 不会逃逸，结果就是大量对象被扔进堆，GC 扫描压力陡增。
- HTTP 中间件里对每个请求都
reflect.ValueOf(req).MethodByName("Header")，它大概率是你 pprof 里最亮的函数之一 -
reflect.Type是只读且全局唯一的，缓存它几乎零成本、收益极高 -
reflect.Value不可复用——它绑定了具体值的生命周期和可寻址性状态，缓存后下次调用可能 panic
CanSet() 返回 false 的常见原因不是字段不可导出，而是没传指针
reflect.Value.Set* 系列方法要求接收者可寻址且可设置，但新手常误以为只要字段首字母大写就行。真实情况是：reflect.ValueOf(struct{}) 得到的是不可寻址的副本，CanSet() 必为 false；必须用 reflect.ValueOf(&s).Elem() 才能获得可设置的 reflect.Value。
这个错误不会立刻报错，而是静默失败或 panic：“call of reflect.Value.Set on zero Value” 或 “cannot set unaddressable value”。调试时容易误判为字段 tag 或类型问题。
- 永远先检查
v.IsValid()和v.CanAddr()，再判断CanSet() - 如果原始变量是值类型（非指针），
reflect.ValueOf(x).Addr()会 panic，必须从&x开始构建 - 结构体字段本身是否导出，只影响
FieldByName是否能拿到该字段，不影响Set能力
Type 和字段索引能缓解部分压力，但无法改变反射调用本身必须走动态路径的事实——这点在设计通用序列化、中间件、校验器时，必须提前划清边界。 
