go 标准库中不存在 reflect.implements 函数，只有 reflect.type 类型的 implements 方法，用于运行时判断某具体类型是否实现指定接口，需先获取 reflect.type 再调用，且参数必须为接口类型。
Go 里没有 reflect.Implements 这个函数
直接说结论：Go 标准库的 reflect 包里压根不存在 reflect.Implements。你搜到的要么是其他语言（比如 C#）的用法，要么是混淆了 reflect.Type.Implements 方法——它属于 reflect.Type 类型的实例方法，不是包级函数。
常见错误现象：undefined: reflect.Implements 编译报错；或误以为传入两个接口类型就能“静态判断”，结果发现根本调不通。
- 必须先用
reflect.TypeOf或reflect.ValueOf获取到具体类型的reflect.Type - 该方法只接受一个参数：
reflect.Type，且必须是接口类型（不能是具体结构体） - 它判断的是「该类型是否实现了某个接口」，而不是「两个接口之间是否有实现关系」
Type.Implements 的正确调用姿势
核心逻辑是：拿一个具体类型的 reflect.Type，调它的 Implements 方法，传入目标接口的 reflect.Type（必须是接口类型）。
使用场景：运行时检查某个变量是否满足某接口契约，比如插件系统中验证用户传入的 handler 是否实现了 http.Handler。
示例：
var h http.Handler = &MyHandler{}
t := reflect.TypeOf(h) // 注意：这里 h 是接口值，TypeOf 返回的是接口类型本身
ifaceType := reflect.TypeOf((*io.Reader)(nil)).Elem() // 获取 *io.Reader 的元素类型（即 io.Reader 接口）
fmt.Println(t.Implements(ifaceType)) // true（如果 MyHandler 实现了 io.Reader）
- ⚠️ 容易踩坑：传入
reflect.TypeOf(&MyHandler{})得到的是*MyHandler的类型，它不等于MyHandler本身，而接口实现检查依赖于具体类型定义 - ⚠️ 必须用
.Elem()提取接口类型的底层类型，否则会 panic：传入指针类型给Implements会报panic: reflect: implements of non-interface type - 性能影响：反射调用有开销，别在热路径反复做；兼容性无问题，Go 1.0+ 都支持
判断「任意值是否实现了某接口」的稳妥写法
比起手动反射，更常见、更安全的做法是类型断言 + 反射兜底：先尝试断言，失败再用反射查。因为多数时候你知道值大概是什么类型。
但若必须纯反射（比如只拿到 interface{} 且不确定底层类型），注意以下几点：
- 用
reflect.ValueOf(x).Type()而不是reflect.TypeOf(x)—— 后者对接口值返回接口类型，前者对非接口值才返回具体类型 - 如果
x是接口值（如var i interface{} = someHandler），reflect.ValueOf(i).Type()返回的是接口类型，此时Implements检查的是该接口是否实现了目标接口（即接口嵌套关系），不是底层实现类型 - 真正想查底层实现？得先
reflect.ValueOf(x).Elem()解包（仅当是接口且非 nil），再取Type()，但这一步极易 panic，务必加CanInterface()和Kind() == reflect.Interface判断
替代方案：用空接口断言更轻量
90% 的实际需求其实不需要反射。比如验证传参是否实现了 io.Writer，直接写：
if _, ok := v.(io.Writer); ok {
// 安全使用
}
这比反射快一个数量级，代码清晰，且编译期就能捕获类型错误。
只有两种情况才值得上反射：
- 你完全不知道传入值的静态类型（比如配置驱动的工厂函数）
- 要批量检查一组未知类型的值，并统一做接口适配逻辑
复杂点在于：反射查接口实现时，Implements 对指针接收器和值接收器的处理是一致的，但你得确保传入的是正确的类型层级——少一层 Elem()，或多一层 Indirect()，结果就完全不对。
