应直接调用 reflect.Type.NumMethod()，无需缓存其返回值；真正需缓存的是 reflect.Type 实例本身，避免反复调用 reflect.TypeOf 或 reflect.ValueOf。
直接用 reflect.Type.NumMethod()，别缓存它，也别在热路径反复调用 reflect.TypeOf —— 这是唯一合理做法。
为什么 NumMethod 本身不值得优化
NumMethod() 是个纯读取操作，内部只返回类型结构体里一个预计算好的字段（numMethod），没有字符串比较、不遍历方法表、不分配内存。它和 len([]int) 一样廉价，压根不是瓶颈。
真正拖慢的从来不是这个方法，而是你每次调用它前做的两件事：
- 用
reflect.TypeOf(x)拿到reflect.Type—— 这会查全局类型表、做接口转换、分配临时对象 - 把任意值（比如
interface{}）传给reflect.TypeOf—— 如果该值是接口，底层还要解包再查具体类型
缓存 reflect.Type 而非 NumMethod 结果
你要缓存的是 reflect.Type 实例本身，不是它返回的数字。因为：
立即学习“go语言免费学习笔记（深入）”；
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 同一类型的
reflect.Type在整个程序中地址恒定，可安全作 key - 用
uintptr(unsafe.Pointer(t))当 map key 零开销，比t.String()快且稳定 - 缓存
map[uintptr]int纯属多余：既然已有reflect.Type，直接调.NumMethod()更快
错误示范：methodCountCache[reflect.TypeOf(v).String()] = t.NumMethod() —— 字符串拼接 + 哈希 + 内存分配，全白干。
热路径别碰 reflect.ValueOf + NumMethod 组合
如果你在循环里写类似 reflect.ValueOf(x).Type().NumMethod()，等于每轮都触发两次反射开销（ValueOf + Type()）。正确姿势是：
- 提前把类型信息提出来：
t := reflect.TypeOf(x)，然后复用t.NumMethod() - 若
x是接口类型，且实际值类型固定（如总是*User），直接用reflect.TypeOf((*User)(nil)).Elem()获取，绕过运行时类型推导 - 如果只是判断“有没有方法”，别用
NumMethod() == 0，改用reflect.ValueOf(x).Method(0).IsValid()（但仅限极少数场景，多数时候不如直接硬编码）
真正要警惕的其实是 Method(i) 调用本身
NumMethod() 只是告诉你有多少个，但后续遍历调用 Method(i) 才是重头戏。这里容易踩的坑：
-
Method(i)返回的是reflect.Method，含名字、类型、函数指针；但每次调用仍需查表，建议缓存整个[]reflect.Method切片（按类型缓存） - 若只关心某几个固定方法名（如
"MarshalJSON"），别用循环找，直接t.MethodByName("MarshalJSON")—— 它内部是哈希查找，比线性遍历快，且结果可缓存 - 调用
reflect.Value.Call开销极大（栈帧构建、参数校验、反射函数调用），高频场景必须用代码生成或unsafe闭包替代
字段数量能数清，方法数量也数得快；但数完之后怎么用，才是性能分水岭。别在计数上浪费精力，盯紧 MethodByName 和 Call 这两个真·重操作。
