reflect.ValueOf接口值后无法直接调用接口方法，因MethodByName只查具体类型方法；需先Elem()获取底层值，确保导出且接收者匹配，或用TypeOf遍历接口方法集。
reflect.ValueOf 接口值后无法调用方法？
直接对接口变量调用 reflect.ValueOf 得到的是接口底层的 concrete value，但它的方法集只包含接口声明的方法 —— 而反射系统默认不自动“升格”为接口类型的方法调用。如果你拿到一个 interface{}，里面装着实现了某个接口的结构体，却想通过反射调用该接口定义的方法（而非结构体自己的导出方法），会失败。
常见错误现象：MethodByName("DoSomething").IsValid() 返回 false，即使接口定义了该方法。
- 必须先确认该接口值底层实际是什么类型：用
v := reflect.ValueOf(iface); v.Kind() == reflect.Interface判断，再用v.Elem()获取真实值 - 接口方法不能靠
MethodByName直接查 —— 它只查 concrete type 的方法，不是接口方法表 - 真正想调用接口方法，应先断言或用
v.MethodByName查 concrete type 的同名方法（前提是它导出且签名匹配） - 更稳妥的做法是：把接口转成具体类型指针再反射，或用
reflect.TypeOf(iface).Method(i)遍历接口的 MethodSet（但仅限获取信息，不能直接 Call）
动态调用 interface{} 中结构体的导出方法
这是最常用也最容易踩坑的场景：你有一个 interface{}，知道它背后是某个结构体指针，想按名字调用其方法。关键点不在“接口”，而在“是否导出 + 接收者类型是否匹配”。
- 方法必须首字母大写（导出），否则
MethodByName找不到 - 如果原值是结构体值（非指针），而方法接收者是指针（
func (s *MyStruct) Foo()），则reflect.ValueOf(s).MethodByName("Foo")会失效 —— 必须传指针：reflect.ValueOf(&s) - 调用前务必检查
method.IsValid() && method.Kind() == reflect.Func - 参数必须全为
reflect.Value，且类型、数量严格匹配；返回值也是[]reflect.Value，需手动解包
示例：reflect.ValueOf(&obj).MethodByName("Save").Call([]reflect.Value{}) —— 注意这里传的是 &obj，不是 obj。
立即学习“go语言免费学习笔记（深入）”；
CanSet() 为什么总返回 false？
几乎所有想用反射修改字段或变量值的人，第一步都会卡在这里。根本原因不是代码写错了，而是 Go 反射对“可设置性”有硬性限制。
-
reflect.ValueOf(x)得到的值永远不可设（CanSet() == false），无论x是什么类型 - 只有通过指针进入才能获得可设权限：
reflect.ValueOf(&x).Elem()，且x本身必须是地址可取的变量（不能是字面量、常量、函数返回值等） - 结构体字段要可设，不仅需要指针路径，字段名还必须首字母大写（导出）
- 对
interface{}做Elem()前，必须确保它装的是指针 —— 否则 panic: “call of reflect.Value.Elem on interface Value”
性能与可维护性的真实代价
反射调用比直接调用慢 10–100 倍不止，但这不是最麻烦的。真正容易被忽略的是：一旦你依赖 MethodByName 或字段名字符串，就等于把编译期检查移到了运行时 —— 拼错方法名、参数类型变更、结构体重构，全部变成 panic。
建议只在以下情况用反射调接口方法：
- 框架层统一调度（如 RPC 方法分发、Web 路由绑定）
- 配置驱动的行为（如 CLI 命令映射到 struct 方法）
- 测试辅助工具（如自动生成 mock 行为）
日常业务逻辑中，优先用类型断言或接口多态；真要动态，也尽量用 map[string]func() 封装已知方法，而不是裸反射。字符串即契约，它不会提醒你重构失败。
