根本原因是每次调用重复执行reflect.TypeOf、reflect.ValueOf和MethodByName，导致高频下GC激增、CPU耗时翻3–5倍；应缓存reflect.Type和methodInfo，key用uintptr(unsafe.Pointer(t))，禁用reflect.Value缓存与sync.Map存类型。
缓存 reflect.Type 和方法索引能显著缓解动态代理的性能瓶颈，但不能靠缓存 reflect.Value 或用 sync.Map 存类型来“假装优化”。
为什么动态代理一高频就慢？
根本原因不是“用了反射”，而是每次调用都重复做三件事：reflect.TypeOf 查类型表、reflect.ValueOf 分配新结构体、MethodByName 线性遍历方法列表。实测在每秒 10 万次代理调用下，GC 分配量翻倍，CPU 时间多出 3–5 倍。
更隐蔽的问题是：你写的“代理对象”如果每次 Call 都重新 reflect.ValueOf(target)，等于把零值缓存当真用了——它不省时间，只骗自己。
- 同一类型的
reflect.Type指针地址恒定，可安全作 key -
reflect.Value每次都是新实例，不可比较、不能当 map key - 接口变量传入
reflect.ValueOf后，若底层是 nil，MethodByName返回零值，Call必 panic
缓存什么？怎么选 key？
只缓存两类东西：reflect.Type（用于后续字段/方法查找）和预计算的 methodInfo 结构（含 reflect.Method 实例、参数个数、返回值类型等）。key 必须是零开销、稳定、无歧义的。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 推荐 key：
uintptr(unsafe.Pointer(t))，取reflect.TypeOf(x).UnsafePointer()的地址，标准库（如encoding/json）就这么干 - ❌ 避免 key：
t.String()（匿名 struct 返回空字符串）、t.PkgPath() + "." + t.Name()（vendoring 或多模块时路径可能冲突） - ❌ 别用
map[interface{}]T：不同变量即使类型相同，接口底层的值指针不同，无法命中 - ❌ 别用
sync.Map存类型缓存：读多写少场景下，它的原子操作比map[uintptr]T+sync.RWMutex更慢
如何避免 MethodByName 的 O(n) 开销？
MethodByName 是动态代理里最常被忽略的热点——它内部循环比对方法名字符串。10 个方法就要比 10 次；若代理对象有 50 个方法，且每个请求调用其中 3 个，那光字符串匹配就吃掉大量 CPU。
- 提前遍历
t.NumMethod()，用map[string]int缓存方法名到索引的映射 - 后续直接用
v.Method(i).Call(args)，跳过全部字符串操作 - 这个映射本身也该缓存，key 用
uintptr(unsafe.Pointer(t))，value 是map[string]int - 不要在
init()里预热所有类型——你根本不知道哪些会被代理，纯属浪费内存
真正快的代理，根本不碰 reflect.Value.Call
缓存只是“减损”，不是根治。热路径上最有效的做法，是在初始化时用 unsafe.Offsetof 算出方法入口偏移，再用 reflect.MakeFunc 生成闭包——运行时只剩指针加法和函数跳转，无反射、无分配、无 panic 风险。
- 示例：对
*MyService.DoAction，预计算其在类型虚表中的偏移，封装为func() string闭包 - 这种闭包可复用，且类型安全：输入输出签名由编译器校验，不会出现
Call时参数数量错或类型不匹配 - 注意前提：目标方法必须导出、签名稳定、接收者类型一致（比如全是
*T） - 一旦结构体字段顺序变动或方法签名升级，这类闭包会静默失效——所以只适合内部服务、协议固定、发布受控的场景
最后提醒一句：如果你的代理逻辑里还混着 recover() 包裹 Call、或者每次调用都 make([]reflect.Value) 参数切片，那缓存类型只是给跑车换轮胎，引擎还是拖拉机。真正的优化点，在于把“反射调用”变成“直接调用”。
