reflect.type.method 比直接查方法表慢，因其每次调用需线性遍历、字符串哈希比对且无法内联；methodbyname 平均查15次，耗时12–18 ns，而缓存 method(i) 仅0.3 ns，快40倍以上。
reflect.Type.Method 为什么比直接查方法表慢
因为 reflect.Type.Method 每次调用都要遍历整个方法表、做字符串哈希 + 比对，且无法内联。Go 的方法表是按字典序排列的切片，不是哈希表，MethodByName 是线性查找 —— 一个带 30 个方法的类型，平均要查 15 次才能命中。
实测显示，MethodByName("Handle") 单次耗时约 12–18 ns；而缓存后的 Method(2)（假设 Handle 在索引 2）仅需 0.3 ns 左右，快 40 倍以上。
- 方法顺序在编译后是稳定的（除非改源码或加 build tag），所以
Method(i)安全可用 -
MethodByName还会触发额外的字符串分配（如传入的"Handle"被转成内部reflect.name结构） - 泛型函数里不能用
MethodByName做分支，因为类型参数在编译期未知，运行时查表开销无法避免
缓存 Method 结果该用什么当 key
必须用 uintptr(unsafe.Pointer(t))，而不是 t.String() 或 interface{}。
t.String() 对匿名 struct 返回空字符串，对 vendored 包可能因路径不同生成重复名；map[interface{}]T 则因接口底层含值指针，相同类型的不同变量无法命中缓存。
- 正确方式：
cache.LoadOrStore(uintptr(unsafe.Pointer(t)), buildMethodMap(t)) -
buildMethodMap(t)返回map[string]reflect.Method，只在首次访问时构建 - 不缓存
reflect.Value.Method(i)—— 它绑定了具体实例，每次调用都新建，毫无复用价值
Method.Call 的真正瓶颈不在“调用”，而在校验和装包
reflect.Value.Call 慢不是因为跳转本身，而是每次都要重做三件事：检查 receiver 是否可寻址、逐个校验参数类型是否匹配、把 []reflect.Value 打包成 runtime 可识别的栈帧格式。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
压测显示，空方法 func() {} 直接调用耗时约 1.2 ns；用 reflect.Value.Call 稳定在 80–120 ns —— 校验和装包占了 95% 以上开销。
- 必须确保 receiver 是指针：
reflect.ValueOf(&s).Method(0).Call(args)，否则 panic - 参数
[]reflect.Value中每个元素必须严格匹配签名，int和int64不自动转换 - 高频场景下，优先用
reflect.MakeFunc生成闭包，把校验移到初始化阶段
哪些地方根本绕不开 Method 反射
只有三类场景真正刚性依赖运行时方法反射：HTTP handler 注册（如 http.HandleFunc 接收任意函数）、插件系统动态加载未声明类型的方法、调试器实时调用对象方法（如 delve 的 call obj.Method()）。
这些地方无法预生成、无法用泛型替代，只能接受代价，但必须加约束：
- 限制调用频次：只在 debug 模式启用，或按请求采样率控制（如 0.1%）
- 限制输入规模：禁止嵌套过深的结构体作为 receiver，避免
reflect.Value逃逸到堆上 - 禁用
MethodByName：所有注册点强制要求方法索引或提前解析好reflect.Method实例
最容易被忽略的是：哪怕你缓存了 reflect.Method，只要还在热路径里调 .Call()，就仍卡在最重的那条路径上 —— 缓存只是省了 15% 开销，剩下 85% 仍在 runtime 层反复校验。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
