怎么用 reflect.Type 判断一个类型是否实现接口
不能直接用 reflect.Type 判断——它只描述结构，不包含方法集信息。必须用 reflect.Interface 或 reflect.Value 的实际值才能查方法集。
常见错误是传入 reflect.TypeOf(&MyStruct{}) 后调用 .Implements()，结果 panic：因为 reflect.Type 没有 Implements 方法。
- 正确做法：先用
reflect.ValueOf(interface{}(someValue)).Type()拿到类型，再确保这个值是非 nil 的接口或具体类型实例 - 更稳妥路径：用
reflect.TypeOf((*MyStruct)(nil)).Elem()获取指针解引用后的类型，再配合reflect.ValueOf构造可检查的实例 - 如果只有类型名（如字符串
"main.MyStruct"），得靠reflect.ValueOf+ 空结构体占位，否则无法触发方法集解析
reflect.Value.Implements() 的实际用法和限制
这个方法存在，但只能在 reflect.Value 是接口类型或实现了目标接口的具体值时才安全调用；传入未初始化的指针、nil 接口或非导出字段会直接 panic。
典型错误现象：panic: reflect: Value.Implements of zero Value，说明 reflect.Value 是零值（比如 reflect.ValueOf(nil)）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须保证
reflect.Value对应真实可取址的值，例如reflect.ValueOf(&MyStruct{})或reflect.ValueOf(MyStruct{}) - 接口类型要提前定义好，且必须是导出接口（首字母大写），否则
reflect看不到其方法 - 注意值接收者 vs 指针接收者：
MyStruct{}能判断是否实现值接收者接口，但可能无法通过指针接收者接口；反之&MyStruct{}更通用
替代方案：用空接口断言 + reflect.Type.AssignableTo()
不依赖运行时值，纯类型层面判断是否“能赋值给某接口”，适合配置驱动或代码生成场景。
原理是：如果类型 T 实现了接口 I，那么 *T 或 T 的类型一定能被赋值给 I，即 reflect.TypeOf((*T)(nil)).Elem().AssignableTo(reflect.TypeOf((*I)(nil)).Elem())。
- 步骤：先构造接口类型的指针类型，再
.Elem()拿到接口本身；对目标类型同理，最后用AssignableTo() - 兼容性好，不 panic，但仅做静态兼容判断，不校验方法签名是否真匹配（比如参数名不同但类型相同仍会返回 true）
- 不能检测嵌入接口的深层实现，比如
type A interface{ B }中B是否被满足，得递归展开
为什么 Implements 不是 reflect.Type 的方法
Go 的接口满足关系是在运行时由方法集决定的，而 reflect.Type 只描述类型结构（字段、名称、包路径），不携带方法信息；方法集绑定在具体值上，所以必须通过 reflect.Value 触发。
容易忽略的一点：同一个类型，T 和 *T 的方法集可能完全不同——比如只有 *T 实现了某个接口，那你用 reflect.ValueOf(T{}) 去调 Implements 就会返回 false，即使逻辑上你认为“它该算实现”。
这事没法绕开，得根据使用场景选值类型：序列化常用值类型，DI 容器常用指针类型。
