reflect.Type 不是接口而是 *rtype 的别名，是编译器生成的未导出结构体，不可构造或修改；其方法通过 runtime 动态计算，Implements 依据接收者类型推导方法集而非查表。
reflect.Type 不是接口，而是 reflect.rtype 的别名，它是一个未导出的运行时底层结构体，不能直接构造或修改。
为什么 reflect.Type 看起来像接口但实际不是
你写 reflect.TypeOf(42) 得到一个 reflect.Type，它在源码里定义为：
type Type interface { ... } // 这是文档里的“接口描述”，不是真实类型
但实际运行时，reflect.Type 是 *rtype（指针）的别名，而 rtype 是 runtime 包中未导出的 struct：
type rtype struct {
size uintptr
ptrdata uintptr
hash uint32
tflag tflag
align uint8
fieldalign uint8
kind uint8
alg *typeAlg
gcdata *byte
str nameOff
ptrToThis typeOff
// ... 更多字段
}
这个结构体由编译器在构建二进制时生成并填充，用户代码无法直接访问或实例化。
立即学习“go语言免费学习笔记（深入）”；
-
reflect.TypeOf返回的不是“接口值”，而是运行时类型描述符的只读视图 - 所有
reflect.Type方法（如.Name()、.Kind()、.Implements()）最终都通过rtype字段和 runtime 函数计算得出 - 你无法用
new(rtype)或&rtype{}创建合法的reflect.Type——会 panic 或崩溃
reflect.Type 和接口实现无关，别被名字误导
名字里带 “Type” 容易让人以为它能表示“某个类型是否实现了某接口”，但它本身不存储实现关系。接口实现是编译期静态检查的结果，rtype 只存方法签名列表（methods 字段），不存“实现了哪些接口”的映射表。
-
t.Implements(ifaceType)不是从rtype查表，而是运行时动态比对方法集：遍历t的所有方法，确认是否完全覆盖ifaceType要求的方法（含接收者类型匹配） - 如果
ifaceType本身不是接口类型（比如传了reflect.TypeOf(struct{}{})），Implements直接 panic，因为底层逻辑要求第一个参数必须是kind == reflect.Interface的rtype -
rtype没有字段叫implementedInterfaces，Go 运行时根本没维护这个信息
真正影响 Implements 结果的是接收者类型，不是 rtype 结构
同一个结构体 MyStruct，其 rtype 在内存里只有一份，但 reflect.TypeOf(MyStruct{}) 和 reflect.TypeOf(&MyStruct{}) 返回两个不同的 reflect.Type，因为它们对应不同 kind 的 rtype：
-
reflect.TypeOf(MyStruct{})→kind == reflect.Struct，方法集只含值接收器方法 -
reflect.TypeOf(&MyStruct{})→kind == reflect.Ptr，方法集包含值+指针接收器方法 - 所以
reflect.TypeOf(MyStruct{}).Implements(iface)和reflect.TypeOf(&MyStruct{}).Implements(iface)可能返回不同结果
这不是 rtype 本身有分支逻辑，而是 Implements 方法内部根据 kind 和接收者规则重新推导方法集。
真正容易被忽略的点：你永远不该试图“构造”或“伪造” reflect.Type；它的唯一合法来源是 reflect.TypeOf、reflect.Value.Type() 或 reflect.TypeOf((*YourInterface)(nil)).Elem()。任何绕过这些路径的操作，都会脱离 Go 类型系统的约束边界。
