methodbyname有15–20%开销，需在初始化时缓存而非热路径反复查；必须校验isvalid()和cancall()才可安全call，否则易panic。
MethodByName 调用本身就有开销，别在热路径反复查
每次 MethodByName 都要哈希字符串、遍历类型的方法表（按字母序排列），实测占整个反射调用链 15–20% 的时间。它不是“查个 map”，而是线性扫描 + 字符串比对。
常见错误是把 MethodByName 放在循环里、HTTP handler 中或高频事件回调中：
- ❌ 错误：每次请求都
t.MethodByName("Validate") - ✅ 正确：在包初始化或结构体首次使用时缓存结果，比如
validateMethod = t.MethodByName("Validate") - 缓存对象推荐用
reflect.Method（结构体，无指针、无逃逸），而不是reflect.Value—— 后者绑定了具体接收者，可能造成 GC 问题或 dangling pointer
用 NumMethod + Method(i) 遍历时，别依赖顺序或拼写
NumMethod 只返回导出方法数，Method(i) 按字母序返回第 i 个方法，不是定义顺序。所以不能靠索引硬编码，比如 Method(0) 不一定对应 Save。
更可靠的做法是遍历并显式比对名称：
- 用
strings.EqualFold做大小写不敏感比较（仅当业务允许时） - 避免直接
m.Name == "Save"—— 如果方法名来自配置或用户输入，先 trim 空格、验证是否全为 ASCII 字母 - 注意：
Method(i).Name永远是首字母大写的导出名；小写方法（如save）根本不会出现在列表里
接收者类型不匹配会导致 MethodByName 返回零值
MethodByName 查不到方法，90% 是因为传入的 reflect.Type 和目标方法的接收者类型不一致。例如：
- 方法定义在
*MyStruct上，但你用了reflect.TypeOf(MyStruct{})→ 查不到 - 方法定义在
MyStruct上，但你用了reflect.TypeOf(&MyStruct{})→ 也查不到 - 正确做法：确认方法签名，再选对类型。常用组合：
reflect.TypeOf((*MyStruct)(nil)).Elem()得到值类型；reflect.TypeOf(&MyStruct{})得到指针类型
缓存后仍要检查 IsValid 和 CanCall
缓存了 reflect.Method 或其 reflect.Value，不代表调用就安全。运行时接收者可能为 nil、不可寻址、或未导出。
必须在每次 Call 前加两道检查：
-
if !method.IsValid()—— 判断是否是零值（比如MethodByName没找到） -
if !method.CanCall()—— 判断接收者是否可调用（常见于 nil 接口、未导出接收者、或非导出字段嵌套） - 别省略任何一步：漏掉
IsValid会 panic"call of reflect.Value.Call on zero Value"；漏掉CanCall可能静默失败或 panic “call of unexported method”
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
