缓存 reflect.Method 能省15–20%开销，关键是以 uintptr(unsafe.Pointer(t)) 为 key 缓存 method；FieldByName 同样需预计算字段偏移以避免 O(n) 查找。
reflect.Value.Call 本身不是瓶颈，真正拖慢的是每次调用前的 receiver 校验和参数类型转换 —— 高频场景下，缓存 reflect.Method 能省 15–20% 开销，但不碰 Call 这一环，性能就卡死在原地。
为什么缓存 reflect.Value.MethodByName 没用
很多人把 v.MethodByName("Foo") 的结果存进 map，以为能提速。其实这只是跳过了字符串哈希和方法表遍历（占总开销小头），Call 前仍要重复做三件事：检查 receiver 是否可寻址、逐个校验参数类型是否匹配、把 []reflect.Value 拆包转成底层栈帧格式。
- receiver 必须是指针：
reflect.ValueOf(&v)，传reflect.ValueOf(v)直接 panic “call of reflect.Value.Call on zero Value” - 参数类型严格区分：
int和int64视为不同，不显式调用.Convert()就 panic -
reflect.Value不能当缓存 key —— 每次调用都新建，地址不同，map 查不到
真正该缓存什么：用 uintptr(unsafe.Pointer(t)) 键值对存 reflect.Method
同一类型的 reflect.Type 在整个进程生命周期中地址唯一且稳定；reflect.Method 是只读结构体，查出来就能复用。关键是怎么建 key。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 正确 key：
cache[uintptr(unsafe.Pointer(t))]["Foo"] = method，其中t = reflect.TypeOf(&v).Elem() - ❌ 错误 key：
t.String()（匿名 struct 返回空字符串）、t.PkgPath() + "." + t.Name()（vendoring 多版本下可能冲突） - 缓存内容建议是结构体：
struct{ method reflect.Value; in, out []reflect.Type }，方便后续预检参数数量和类型
热路径上彻底绕过 Call：用 reflect.MakeFunc 生成闭包
适用于签名固定的方法（如所有 handler 都是 func(ctx context.Context) error）。它在初始化阶段生成一个纯函数，运行时零反射开销，但代价是失去编译期类型检查。
- 必须提前拿到方法签名：
typ := reflect.TypeOf((*MyStruct)(nil)).Method(0).Type - 桥接函数里漏掉
args[0].Interface()解包 receiver，或少 return 一个reflect.Value，运行时直接 crash - 生成的函数无法被
go vet或 IDE 检查，必须靠单元测试覆盖常见入参组合 - 性能比原生函数低 20–50 倍，但比反复
Call快 5–10 倍，且 GC 分配趋近于零
最易被忽略的点：字段访问也得绕开 FieldByName
如果你的“动态调用”链路还包含结构体字段读写（比如从 HTTP 请求解析参数到 struct 字段），FieldByName 是另一个隐藏瓶颈 —— 它内部是 O(n) 字符串遍历。100 字段的 struct 就要比较 100 次。
- 正确做法：启动时用
reflect.TypeOf(T{}).Field(i)预算字段偏移unsafe.Offsetof(T{}.Name)，封装成func(v interface{}) string闭包 - 输入必须是可寻址的（通常传指针），且字段布局不能变；否则 offset 错位，读到垃圾内存
- 这种方案在 msgpack、gogoprotobuf 等高性能序列化库中已验证有效
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
