Go反射不动态获取类型信息，而是读取编译期静态嵌入的runtime._type结构体；interface{}值自带type指针，reflect.TypeOf/ValueOf均从中提取；未导出字段和泛型约束信息编译时即被剥离。
Go 的反射在运行时并不“动态获取”类型信息，而是直接访问编译期已写入二进制的 runtime._type 结构体——这些数据在链接阶段就被静态嵌入到程序中，反射只是读取它们。
Go 类型信息在编译后就固定在二进制里
Go 编译器（gc）会为每个具名类型、底层类型和接口类型生成唯一的 runtime._type 实例，并将其作为只读数据段的一部分写入最终的可执行文件。你调用 reflect.TypeOf(x) 时，实际是通过 x 的底层指针快速查表，定位到对应 *runtime._type 的地址。
- 没有运行时类型推断或解析；不存在类似 Java 的 ClassLoader 或 C++ RTTI 的动态注册机制
-
interface{}值本身携带两个指针：data（指向值）和type（指向*runtime._type），反射直接解引用后者 - 即使关闭
-gcflags="-l"（禁用内联），也不会影响类型信息的存在性或布局
reflect.TypeOf 和 reflect.ValueOf 的底层跳转路径
这两个函数最终都走向 runtime.typelinks 提供的静态索引，但入口不同：
-
reflect.TypeOf(x)→runtime.typeof→ 从x的 interface header 中提取type字段 -
reflect.ValueOf(x)→reflect.valueInterface→ 同样读取 interface header，再构造reflect.Value并缓存其typ字段 - 对非接口值（如
int(42)）传入，编译器会自动装箱为interface{}，所以仍能拿到 type 指针
package main
import (
"fmt"
"reflect"
"unsafe"
)
func main() {
x := 42
v := reflect.ValueOf(x)
// 底层就是读取 x 装箱后 interface{} 的 type 字段
fmt.Printf("type ptr: %p\n", unsafe.Pointer(v.Type().(*reflect.rtype).ptr))
}
为什么不能反射未导出字段或泛型类型参数？
不是因为运行时“拿不到”，而是编译器根本没把这部分信息写进去：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“go语言免费学习笔记（深入）”；
- 结构体未导出字段的名称、偏移量等元数据在编译时被剥离（仅保留内存布局），
reflect.StructField.Name返回空字符串 - 泛型实例化后的类型（如
map[string]int）有完整_type，但类型参数约束（如type T interface{~int}）不生成独立类型描述，仅用于编译期检查 -
unsafe.Sizeof和unsafe.Offsetof可以绕过反射访问私有字段布局，但这是未定义行为，且不提供名字或类型语义
反射性能开销主要来自哪？
不是“查找类型”，而是后续的动态操作：
- 类型断言和转换（
v.Interface()）需校验*_type是否匹配，但仍是 O(1) 比较 - 调用方法（
v.Method(i).Call()）要查runtime._type.methods表，再跳转到函数指针，比直接调用多 2–3 层间接寻址 - 最重的是
reflect.Value构造和复制：每次reflect.ValueOf都会拷贝值（除非是指针），大结构体开销明显
真正难处理的是类型擦除后的语义丢失——比如你拿到一个 reflect.Value，却无法知道它原本是不是某个自定义类型别名，或者是否实现了某个未导出接口。这类信息在编译后就不复存在了。
