reflect.Type.Method 和 reflect.Type.MethodByName 有什么区别
直接说结论：Method 按索引取，MethodByName 按名字查；前者只返回导出方法（首字母大写），后者对未导出方法返回零值。很多人以为 MethodByName 能拿到私有方法，其实不能——Go 的反射严格遵循可见性规则。
常见错误现象：MethodByName("foo") 返回 nil，但结构体里明明定义了 func (t *T) foo() {} ——问题八成出在 foo 是小写开头。
-
Method(i)：i 超出NumMethod()范围会 panic，务必先校验 -
MethodByName(name)：name 区分大小写，且不支持嵌入字段的“继承式”查找 - 两者都只作用于类型本身声明的方法，不包含接口实现的隐式方法
用 reflect.Value.Call 调用 Method 获取到的方法时为啥 panic
因为 Method 返回的是 reflect.Method，它只是方法元信息（名字、类型、函数指针等），不是可调用的 reflect.Value。直接 call() 必然 panic：“call of reflect.Value.Call on zero Value”。
正确路径是：先用 Method 或 MethodByName 拿到 reflect.Method，再用它的 Func 字段得到 reflect.Value，最后调用。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保原始
reflect.Value是可寻址的（比如来自&v而非v），否则无法调用指针接收者方法 - 如果方法接收者是
*T，但你传入的是reflect.ValueOf(v)（v 是 T 类型值），Call 会失败；得用reflect.ValueOf(&v).Elem() - 参数要按签名顺序传
[]reflect.Value，类型不匹配不会编译报错，而是在运行时报 “wrong type for parameter”
动态代理中怎么安全地转发方法调用
核心是别硬编码方法名，也别用 switch 枚举所有方法——要用 MethodByName + Func.Call 做泛化转发，但必须加兜底和类型检查。
典型场景：给某个接口类型做日志代理、权限拦截或 mock 测试桩。重点不是“能调”，而是“调得稳”。
- 先用
t := reflect.TypeOf(proxy).Elem()拿到被代理类型的reflect.Type，注意 Elem() 是因为代理通常持有一个指针字段 - 调用前检查
method, ok := t.MethodByName(methodName)，!ok就该走 panic 或 error 返回，不能静默忽略 - 避免把
context.Context或error这类高频参数手动拆包塞进[]reflect.Value，容易漏或错位；建议封装一个callMethod(v reflect.Value, name string, args ...interface{}) ([]reflect.Value, error) - 性能影响明显：一次反射调用比直接调用慢 10–100 倍，高频路径别滥用；可配合
sync.Map缓存reflect.Method.Func的reflect.Value
为什么代理后 interface{} 转回原类型失败
反射调用返回的 []reflect.Value 里，如果原方法返回 error，你直接 .Interface() 得到的是 interface{}，不是具体 error 实现；更麻烦的是，如果方法返回自定义接口（如 io.Reader），但底层值是未导出结构体，.Interface() 会 panic：“cannot return unexported struct”。
这不是代理写错了，是 Go 反射的硬限制：无法通过反射暴露未导出字段或类型。
- 若需返回具体类型，代理方法里应显式做类型断言或转换，而不是依赖
reflect.Value.Interface() - 对返回值是接口的情况，优先用
reflect.Value.Convert转成目标接口类型（前提是底层值实现了该接口） - 最稳妥的做法：代理层只处理逻辑，返回值由上层显式声明类型，避免在反射链路里做跨包类型还原
真正难的从来不是怎么调，而是怎么让调完的结果还能被外面安心用——这点很容易被忽略，直到线上 panic 才发现返回值一碰就崩。
