reflect.value.methodbyname本质是线性字符串查找，每次调用遍历方法表逐个比对名称，非哈希也非二分；call主要开销在接收者校验、参数类型检查与栈帧装包，而非函数跳转本身。
reflect.Value.MethodByName 本质是线性字符串查找
Go 的 reflect.Value.MethodByName 每次调用都会遍历类型的方法表，逐个比对方法名字符串——不是哈希查表，也不是二分搜索，就是从头到尾一个一个 strcmp。方法越多，平均比较次数越接近 N/2；若方法名拼错或大小写不对（比如 Save vs save），还得扫完整张表才返回零值。
这和 Java 的 Method 对象可复用完全不同：Go 每次都新建 reflect.Value，且不缓存匹配结果。即使你反复调用同一个结构体的同名方法，只要没手动缓存，就重复扫表。
- 字段/方法名稳定时，改用
reflect.Type.Method(i)直接索引，避免字符串匹配 - 启动时预建
map[string]int缓存方法名→索引映射，后续查表 O(1) - 注意方法顺序受源码声明顺序影响，加新方法或调整位置会导致索引失效
reflect.Value.Call 开销不在“调用”，而在校验与装包
reflect.Value.Call 真正慢的地方不是跳转到函数地址，而是每次都要做三件事：检查接收者是否可寻址、逐个校验参数类型是否匹配、把 []reflect.Value 转成底层栈帧格式。这些操作绕过所有编译器优化，且每次分配新切片，高频调用会推高 GC 压力。
压测显示，空方法直调约 1.2 ns，而 Call 稳定在 80–120 ns —— 慢 100 倍不是因为“反射调用”本身，而是因为重复做编译期已知的事。
- 永远确保 receiver 是指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v) - 缓存
reflect.Method（只读、全局单例），别缓存reflect.Value（每次新建，无复用价值） - 热路径上彻底禁用
Call：提前转成闭包或函数指针，如fn := method.Func; fn.Call(args)
panic “call of reflect.Value.Call on zero Value” 的真实根源
这个 panic 不是因为参数错，而是 reflect.Value 本身无效。最常见链路是：reflect.ValueOf(nil) → 零值 → MethodByName 返回零值 → Call panic。它不报“method not found”，因为连 receiver 都没立住。
另一个隐蔽原因是接收者类型不匹配：比如方法定义为 func(t *User) Save()，但你传了 reflect.ValueOf(User{})（值类型），MethodByName 就直接返回零值——Go 不会自动取地址。
- 调用前必须双重检查：
if !method.IsValid() || !method.CanCall() - 输入是 interface{} 时，先判 nil：
if obj == nil { return errors.New("nil interface") } - 方法名小写、接收者非指针、传入非导出类型，都会让
MethodByName静默失败
真正快的方案：绕开 reflect.Value.Call，而不是优化它
所有“缓存 Method + Call”的优化，都逃不开每次调用前的校验与参数转换。要真正接近原生性能，得绕过 reflect.Value.Call 这一层——用 unsafe 直接构造函数指针调用，或用 go:generate 把反射逻辑移至构建期。
Go 1.14+ 的 internal/abi.Type 布局已稳定，可算出方法表偏移并取出函数地址；或者更稳妥地，为每个关键结构体生成专用调用函数，比如 User_Save(u *User)，完全不碰 reflect。
- 手写
unsafe调用快但脆弱：字段重排、build tag 变动、race detector 都可能 silent fail -
go:generate是平衡点：类型固定 + 高频使用 + 性能敏感时，优先选 ent、sqlboiler 或自定义脚本生成 - 真正难处理的是泛型 deep copy、调试 dump、插件加载等场景——那里反射是刚性需求，只能靠限频、采样、debug-only 控制代价
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
