reflect.method 和 reflect.type.method 本身不慢，真正拖垮性能的是 reflect.value.call；methodbyname 因字符串查找比 method(i) 慢数十倍；name() 和 type() 有额外开销，应避免在热路径中调用。
reflect.Method 和 reflect.Type.Method 本身不慢，真正拖垮性能的是后续调用 reflect.Value.Call —— 它才是签名解析完成后的“执行劫持点”，也是绝大多数人误以为“获取签名就慢”的根源。
MethodByName vs Method(i)：字符串查找 vs 索引查表
获取方法签名时，MethodByName 要遍历类型的方法列表做字符串比对；而 Method(i) 直接按索引取值，无比较、无循环。
- 一个含 15 个方法的结构体，
MethodByName("Do")平均要比较 7–8 次才能命中 -
Method(2)是纯内存偏移访问，耗时稳定在 1–2 ns 级别 - 若方法顺序固定（如生成代码或内部约定），优先用
Method(i)，并在注释中标明含义，例如：// Do at index 2 - 不要在循环内反复调用
MethodByName，哪怕只查一次也应提前提取并缓存reflect.Method实例
Method 结构体字段访问：别碰 Name() 和 Type() 除非真需要
reflect.Method 是个只读结构体，但它的 Name() 和 Type() 方法每次调用都会触发额外开销：
-
m.Name()返回新分配的string，涉及堆分配和字符串拷贝 -
m.Type()返回新的reflect.Type，虽是只读指针，但会触发 runtime 类型元数据查找路径 - 如果只是想判断是否为某个方法，直接比对
m.Func.Pointer()是否等于已知函数地址更轻量 - 若需复用方法签名信息，缓存
reflect.Method值本身即可，它不绑定具体实例，可安全复用
Call 之前那一步：为什么 Method.Signature 不是瓶颈，Call 才是
很多人以为“获取方法签名”这步很重，其实 reflect.Method.Type 只是返回一个 reflect.Type，它指向编译期已存在的 abi.Type。真正的性能断崖发生在 reflect.Value.Call。
-
reflect.Method.Func.Call(args)每次都要：校验参数数量/类型、分配[]reflect.Value切片、拆包每个参数、跳转函数指针、再打包返回值 - 空函数直调约 2 ns；同函数走
Call实测 30–180 ns，慢 15–90 倍 - 热路径中（如 HTTP handler、gRPC interceptor）禁用
Call，改用闭包缓存：fn := m.Func，后续直接fn.Call(args)—— 这能省掉重复的MethodByName查找，但无法省掉Call本身的开销 - 最彻底的优化：把
Call移到构建期，用go:generate为每个目标方法生成专用调用函数，零运行时反射
真正容易被忽略的是：你看到的“方法签名获取”往往只是冰山一角，背后藏着的 Call 或 FieldByName 才是性能黑洞。别只盯着 Method 看，得顺藤摸到它后面那个被反复调用的 Call —— 那才是必须砍掉的链路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
