reflect.Value.MethodByName + Call 开销在于字符串匹配、重建栈帧、参数类型转换；缓存 Method 而非 MethodByName 结果，用 MakeFunc 生成闭包或字段偏移直访可显著提效。
reflect.Value.MethodByName + Call 的开销在哪
这不是“调用慢”，而是每次都在重复做三件事：字符串匹配字段名、重建调用栈帧、转换参数类型。哪怕你缓存了 reflect.Value.MethodByName("Save")，Call 本身仍要走完整运行时路径——校验接收者是否可寻址、参数个数和类型是否匹配、把 []reflect.Value 拷贝进栈、触发汇编入口。压测显示，空方法的 Call 稳定在 80–120 ns，而直接调用仅约 1.2 ns。
常见错误现象：MethodByName 返回 reflect.Value 后直接 Call，没检查 IsValid()；传入值类型而非指针，导致接收者不可寻址，Call panic；参数类型不匹配（比如传 int 却期望 int64），报 reflect: Call using x as type y。
- 必须确保方法是导出的（首字母大写）
- 接收者必须是指针类型，且
reflect.ValueOf(&obj)后再MethodByName - 参数需用
reflect.ValueOf(x)包裹，不能直接传原始值
缓存 Method 而不是 MethodByName 结果
缓存 reflect.Value.MethodByName("Foo") 是无效优化——它每次返回新 reflect.Value，且没省掉 Call 开销。真正该缓存的是 reflect.Method 对应的可调用 reflect.Value，且只在类型首次使用时生成一次。
推荐结构：map[uintptr]struct{ method reflect.Value; in, out []reflect.Type }，用 uintptr(unsafe.Pointer(t)) 当 key，避免 t.String() 在匿名 struct 或 vendoring 下失效；in/out 可用于热路径上预检参数类型，跳过 Call 前的运行时校验。
立即学习“go语言免费学习笔记（深入）”；
- 不要把
reflect.Value当 map key（不可比较） - 不要缓存
reflect.ValueOf(obj).MethodByName(...)，它每次新建 - 缓存时机必须在初始化阶段（如
init()），不能在请求中 lazy 构建
热路径上彻底绕过 Call：用 MakeFunc 生成闭包
当方法签名固定（比如全是 func(context.Context) error），reflect.MakeFunc 可在启动时生成纯函数闭包，后续调用零反射开销。它本质是“编译期替身”：把反射调用转成普通函数调用，内联、逃逸分析、分支预测全恢复。
示例中，fn.Call(args) 实际执行的是手写的 recv.(*MyStruct).Foo(ctx)，不经过任何反射路径。但代价是签名必须完全一致，且无法支持运行时动态方法名（比如从配置读取字符串再调用）。
- 签名变化（如加个
error返回值）会导致MakeFuncpanic - 接收者类型必须明确，不能是 interface{} 或泛型约束类型
- 闭包里用
args[0].Interface()解包接收者，注意类型断言安全
字段偏移直访比 MethodByName 快一个数量级
如果目标只是读写结构体字段（比如 ORM 字段映射、JSON 解析），别用 FieldByName。字段名查找是线性扫描，而内存偏移是常数时间指针运算。只要结构体定义稳定（不改字段顺序、不加删字段、不改 tag 影响对齐），就能在 init() 阶段一次性算出 Offset，之后直接 *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + nameOffset))。
这招在 GORM、ent 等框架底层广泛使用。但要注意：字段重排会让 offset 失效；私有字段（小写）无法通过 CanInterface()，必须用 UnsafeAddr() 配合 go:linkname 或禁用 race detector；//go:notinheap 标记的结构体不能这么干。
- 必须确保字段是 exported（大写开头）
- offset 缓存变量要用
uintptr类型，不能是int - 跨平台编译时，不同架构对齐可能不同，需按 target 构建时计算
最易被忽略的点：反射优化不是“选一个 API 替换”，而是分层决策——字段访问用 offset，固定签名方法用 MakeFunc，仅剩的动态场景才用缓存后的 Method + Call，且必须配参数预检。一旦混用或缓存粒度错，性能反而更差。
