Go中运行时判断接口实现应优先用类型断言，而非reflect.Type.Implements；后者仅适用于已知具体类型的场景，且不能用于interface{}或接口类型本身。
Go 中无法在编译期静态判断一个值是否实现了某个接口，但**运行时可通过 reflect.Type.Implements 或更推荐的类型断言完成判断**——前者检查类型定义是否满足接口契约，后者更安全、高效、符合 Go 惯用法。
用 reflect.Type.Implements 判断具体类型是否实现接口
这个方法只适用于已知具体类型的场景（如 MyStruct 或 *MyStruct），不能用于 interface{} 变量本身，也不能用于接口类型（比如 io.Reader 类型自身调用 Implements 会 panic）。
- 必须传入接口的
reflect.Type，通常用reflect.TypeOf((*YourInterface)(nil)).Elem()获取 - 被检查对象需先通过
reflect.TypeOf()得到reflect.Type，且该类型不能是interface{}或 nil 接口值 - 它只看方法集是否匹配，不关心值是否为 nil 或能否调用
type Stringer interface {
String() string
}
s := struct{}{}
t := reflect.TypeOf(s)
ifaceT := reflect.TypeOf((*Stringer)(nil)).Elem()
fmt.Println(t.Implements(ifaceT)) // false —— struct{} 没有 String 方法
用类型断言替代反射：更推荐的运行时判断方式
当只有一个 interface{} 值（比如函数参数），想确认它底层类型是否实现了某接口时，优先用类型断言而非反射。它更简洁、零开销、可读性强，且天然处理了 nil 值安全问题。
-
v, ok := x.(SomeInterface)是最标准写法；ok为true表示底层值实现了该接口 - 即使
x是 nil 接口值，断言也不会 panic，只会返回nil, false - 不要用
x.(SomeInterface)（无ok）强行断言，否则值不匹配时 panic - 反射在这里是“绕远路”：先取
reflect.ValueOf(x)→ 再取Type()→ 再调Implements，多此一举
var x interface{} = &bytes.Buffer{}
if _, ok := x.(io.Writer); ok {
fmt.Println("x implements io.Writer")
}
常见错误：对 interface{} 直接调 Implements 或误用 reflect.Value
以下写法全部错误，且会在运行时 panic 或返回意外结果：
-
reflect.ValueOf(x).Type().Implements(...)：如果x是 nil 接口值，reflect.ValueOf(x)的Type()返回 nil，调Implementspanic -
reflect.TypeOf(x).Implements(...)：若x是接口类型变量（如var r io.Reader），reflect.TypeOf(r)返回的是接口类型，而接口类型不支持Implements - 把
reflect.Value当作reflect.Type传给Implements：编译不报错但逻辑错，因为Implements是reflect.Type的方法
真正安全的反射路径只有一条：确保输入是具体类型（非接口）、非 nil，并从 reflect.TypeOf(具体值) 得到 Type 后再调用。
什么时候真该用反射做类型判断？
极少。典型合法场景仅限于泛型不可用的老版本 Go（json.Marshaler 等接口。即便如此，也建议优先封装成工具函数隐藏反射细节。
- 日常业务逻辑、API 参数校验、中间件判断——一律用类型断言
- 需要检查指针类型是否实现接口？断言同样适用：
if _, ok := x.(*MyType); ok { ... } - 性能敏感路径（如高频 HTTP handler）中，反射调用比断言慢 10–100 倍，且 GC 压力略高
记住：Go 的接口实现是隐式的、静态的，判断“是否实现”本质是编译器做的事；运行时你要的往往不是“它能不能”，而是“它现在是不是”——后者，断言就足够了。
