Go接口无运行时方法签名，reflect无法获取接口要求的方法列表；只能通过具体实现类型的实例反射其方法，且需用指针接收者确保完整性。
接口本身没有方法签名列表可反射
Go 的 interface{} 类型在运行时只保存具体值（concrete value）和类型信息，不携带“它实现了哪些方法”的元数据。你无法对一个空接口变量或接口类型字面量（如 io.Reader）调用 NumMethod() 或遍历方法 —— reflect.TypeOf((*io.Reader)(nil)).Elem() 会 panic，因为 Elem() 对 reflect.Interface 类型非法。
常见错误现象：reflect.TypeOf(var r io.Reader).NumMethod() 返回的是底层具体类型的导出方法数（比如 *bytes.Buffer 有 20+ 个），不是 io.Reader 要求的 Read([]byte) (int, error) 这一个签名。
- 接口满足性是编译期静态隐式判断，运行时无“接口方法集”这个实体
- 反射能操作的只有 concrete type（如
*MyStruct），不是 interface type 定义 - 想查某个值“是否实现了某接口”，直接用类型断言：
_, ok := r.(io.Closer)，比反射快且安全
要获取方法签名，必须有具体实现类型实例
唯一可行路径：拿到一个实现了目标接口的具体值（比如 &MyReader{}），再用 reflect.TypeOf() 获取其类型，然后遍历 Method(i)。
注意接收者类型影响方法可见性：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传
MyReader{}（值）→ 只能看到值接收者方法 - 传
&MyReader{}（指针）→ 能看到值接收者 + 指针接收者方法（更完整） - 推荐统一用指针：
reflect.TypeOf(&x).Elem()确保覆盖全部导出方法
示例中 MyReader 实现了 io.Reader，但它的 Read 方法是值接收者还是指针接收者，决定了你是否能在反射中稳定看到它 —— 所以别依赖“接口名”，盯住具体实例。
提取参数与返回值类型：In(0) 是接收者，用户参数从 In(1) 开始
reflect.Method.Type 返回的是带接收者的完整函数类型。例如 func (r *MyReader) Read(p []byte) (n int, err error)，其 m.Type.NumIn() == 2，m.Type.In(0) 是 *MyReader，m.Type.In(1) 才是 []byte。
- 先检查
m.Type.NumIn() > 1，再循环i = 1到m.Type.NumIn()-1提取用户参数 -
m.Type.Out(i)直接对应返回值，无需跳过 - 用
m.Type.In(0).Kind() == reflect.Ptr判断是否为指针接收者 - 非导出方法（小写开头）根本不会出现在
Method(i)列表里，不用额外过滤
别试图“匹配接口签名”，手动比对既慢又不可靠
有人想用反射遍历所有方法，再逐个比对名称、参数个数、类型、返回值，来判断是否满足 io.Reader。这不仅代码冗长，还容易漏掉：error 和 *errors.errorString 类型不等价、泛型擦除后类型失真、嵌入字段带来的方法重名等。
真正需要验证实现完整性时：
- 单元测试里直接赋值给接口变量，编译器会报错 —— 最准
- 运行时只需一次断言：
if _, ok := x.(io.Reader); !ok { ... } - 反射只适合调试：比如发现某个结构体意外实现了
fmt.Stringer，想确认是哪个方法干的
接口方法签名不是运行时资源，而是设计契约。拿反射去“还原”它，就像拆解已编译的二进制去反推源码逻辑 —— 能做，但绕远、易错、没必要。
