rtype是Go运行时内部非导出结构体，reflect.Type接口由其实现，但用户代码不可直接访问或操作；它字段只读、布局不保证跨版本稳定，所有反射操作应通过reflect.Type接口方法进行。
rtype 是 reflect.Type 的底层实现，但你不该直接用它
rtype 是 go 运行时内部定义的非导出结构体，reflect.typeof() 返回的 reflect.type 接口实际由它实现。你无法在用户代码中声明或初始化 rtype，也不能用类型断言把它转成 *rtype（会编译失败）。它的存在只为运行时服务，暴露给开发者的只有 reflect.type 接口方法。
- 所有类型（
int、[]string、*User、func(int) bool）在反射中都对应一个rtype实例，地址唯一且生命周期与程序一致 -
rtype字段如size、align、hash都是只读的，修改会导致 panic 或内存损坏 - 你看到的
structType、ptrType等，都是嵌入了rtype的扩展结构体，它们不暴露给用户，仅用于运行时内部 dispatch
比如 reflect.TypeOf(&User{}).Kind() == reflect.Ptr，这个判断不是靠接口方法硬编码，而是通过 (*ptrType)(unsafe.Pointer(t)).elem 向下取指针所指类型 —— 但这段逻辑封装在 rtype 的方法里，你调用 Elem() 就行，不用碰 ptrType。
为什么 TypeOf 返回的是接口，而不是 *rtype
Go 反射设计刻意隐藏了 rtype 的具体布局，因为：
-
rtype字段顺序、大小、对齐方式在不同 Go 版本中可能变化（例如 Go 1.18 加了uncommonType指针，Go 1.21 调整了tflag位域） - 直接操作
rtype会绕过类型安全检查，比如把int的rtype强转成structType，解引用fields字段就会 segfault -
reflect.Type接口方法（如Name()、PkgPath()、Method()）做了完整校验：对未导出字段返回空字符串，对无方法类型返回 0 个方法
你写 t := reflect.TypeOf(x); t.Name()，背后是 (*rtype).name() 方法被调用；但如果你试图 unsafe.Pointer(t) 再强转，就等于跳过所有防护，直面运行时 ABI —— 这不是“高级用法”，是自毁式操作。
常见误用：想从 reflect.Type 拿到 rtype 地址并读字段
这种需求通常出现在想绕过反射 API 做性能优化，或调试类型布局。但现实是：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
reflect.TypeOf(x)返回的reflect.Type是接口值，底层data字段存的是*rtype，但 Go 不允许你用unsafe提取它（interface{}的底层结构在runtime包，且随版本变动） - 即使你用
unsafe硬解reflect.Type接口头（itab + data），拿到的*rtype也无法安全访问其字段：-
rtype.size在某些架构上是 64 位，在 32 位环境是 32 位，直接读会错位 -
rtype.tflag是位域，没有公开的 mask 定义，不同 Go 版本含义不同
-
- 真正需要底层信息的场景（如序列化框架），应使用
reflect.Type.Kind()+reflect.Value.Kind()组合判断，而非解析rtype
例如你想区分 “指针指向结构体” 和 “接口类型”，应该用 t.Kind() == reflect.Ptr && t.Elem().Kind() == reflect.Struct，而不是去读 rtype 的 kind 字段或查 uncommonType 是否为空。
真正该关注的：rtype 如何影响反射性能
rtype 本身不慢，但它的使用方式会带来开销：
-
reflect.TypeOf()和reflect.ValueOf()都要走接口转换 + 类型擦除，比直接类型断言慢 3–5 倍 -
reflect.Type.MethodByName()第一次调用会触发rtype.uncommon()查找并缓存到全局methodCache，后续调用才快；但缓存键是*rtype地址，所以两个等价但不同地址的类型（如不同包定义的同名 struct）不会共享缓存 -
reflect.StructField.Offset是编译期确定的常量，但reflect.Type.FieldByName()是线性遍历fields []structField，字段越多越慢；有大量字段时，建议提前用map[string]int缓存索引
如果你的代码高频调用 FieldByName 或 MethodByName，别想着“把 rtype 字段 dump 出来加速”，正确做法是：在 init 阶段预热一次，把常用字段/方法索引存成包级变量，后续直接查表。
rtype 不是供你读写的内存块，它是 Go 类型系统的只读快照。你依赖它的稳定性，但不该假设它的布局 —— 这正是 reflect 包用接口封装它的根本原因。
