reflect.Value.Call 的性能瓶颈在于每次调用前的 receiver 校验和参数转换，而非 Call 本身；必须绕过它，缓存 reflect.Method 和类型元数据，或用 reflect.MakeFunc/unsafe 预计算方法入口。
reflect.Value.Call 不能靠“调得少”来优化，必须绕过它本身——缓存 reflect.Method 只省掉 15–20% 开销，真正瓶颈在每次调用前的 receiver 校验和参数转换。
为什么 reflect.Value.Call 一调就 panic
最常见原因是传入了不可寻址的值：reflect.ValueOf(v).MethodByName("Foo").Call() 中 v 是值类型（比如 struct{}），reflect.Value 就不是 addressable，立刻 panic “call of reflect.Value.Call on zero Value”。
- 必须确保 receiver 是指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v) - 永远在
Call前加两道保险：if !method.IsValid() || !method.CanCall() - 如果输入是
interface{}，先断言非nil：if obj == nil，再做reflect.ValueOf -
MethodByName返回零值的常见原因：方法名小写、接收者类型不匹配（传了MyStruct{}却要调指针接收者方法）
缓存什么才真正有效：别碰 reflect.Value，只缓存 reflect.Method 和类型元数据
reflect.Method 可以缓存，reflect.Value 缓存等于白干。因为 reflect.Type 和 reflect.Method 是只读、全局单例，同一方法名查出来的实例地址恒定；而 reflect.Value 每次都新建，无法比较、不能当 map key。
- 正确缓存方式：
cache[uintptr(unsafe.Pointer(t))][methodName] = method，其中t是reflect.TypeOf(&v).Elem()得到的结构体类型 - 错误方式：
map[interface{}]reflect.Method（接口底层含值指针，不同变量即使类型相同也无法命中） - 别缓存
reflect.Value.Method(i).Call()的结果——它依赖具体实例，毫无复用价值 - 缓存内容建议是
struct{ method reflect.Value; in, out []reflect.Type }，方便后续做参数校验预检
热路径上彻底绕过 Call：用 reflect.MakeFunc 或 unsafe 预算方法入口
Go 1.14+ 起 internal/abi.Type 布局稳定（x86_64 下 48 字节，方法表项 8 字节），可直接算出方法入口偏移，再用 unsafe 构造函数指针调用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 对固定签名的方法（如所有 handler 都是
func(ctx context.Context) error），用reflect.MakeFunc在初始化阶段生成闭包，运行时零反射开销 - 预计算方法入口地址：
funcPtr := *(*uintptr)(unsafe.Pointer(uintptr(unsafe.Pointer(t)) + offsetToMethodTable + i*8)) - 封装为闭包：
func(v interface{}) { callFunc(funcPtr, v) }，运行时只做指针传递，无反射开销 - 注意：该方式绕过了 Go 类型系统校验，必须确保方法签名和调用参数绝对匹配，否则 runtime crash
最容易被忽略的性能点：校验和参数转换才是真瓶颈，不是 Call 动作本身
哪怕你缓存了 reflect.Method，只要每次调用还走 Call，receiver 可寻址性校验、参数类型逐个转换、临时切片分配、栈帧重建这些步骤就一个不少——实测空方法直调约 1.2 ns，reflect.Value.Call 稳定在 80–120 ns。
字段访问同理：FieldByName 是线性搜索，100 字段就要比 100 次字符串；而 Field(i) 是数组下标访问，常数时间。真正难处理的是那些无法预知类型的场景（如 deep copy 任意 struct、插件系统加载未知类型），这些地方反射是刚性需求，只能接受代价，并严格限制调用频次和输入规模——比如只在 debug 模式启用，或加采样率控制。
