Go reflect包核心不在reflect目录而在runtime/type.go等三处，其TypeOf/ValueOf是假入口，真正逻辑由编译器生成并硬编码于链接阶段。
Go 的 reflect 包不是“能看懂就行”的玩具包，而是运行时类型系统的核心出口；直接读 src/reflect/ 会立刻卡在 rtype、unsafe.Pointer 和大量汇编跳转里——这不是你源码读得慢，是设计上就**不打算让人从顶层函数顺下来读**。
从 ValueOf 和 TypeOf 入口根本走不通
这两个函数看似友好，实则是“假入口”：它们立即调用内部未导出的 unpackEface，而该函数依赖编译器生成的类型元数据结构（runtime._type），且被内联+硬编码到链接阶段。你查不到它的 Go 源码，它在 runtime/iface.go 里只有声明，在 cmd/compile/internal/ssa/gen.go 里才生成实际逻辑。
- 别在
reflect/value.go里逐行跟ValueOf调用链，90% 的关键逻辑不在那里 - 真正承载类型信息的是
runtime._type和runtime.uncommonType，它们定义在runtime/type.go，但字段布局由编译器控制，注释极少 -
reflect.TypeOf(42).Kind()看似简单，实际是：取接口值 → 解包为runtime.eface→ 强转指针 → 读_type.kind字节 → 查表映射为reflect.Kind
reflect.Value 的字段几乎全是 unsafe 操作
reflect.Value 是个只含三个字段的 struct：typ（*rtype）、ptr（unsafe.Pointer）、flag（uintptr）。所有方法如 Int()、Interface() 都基于这三个字段做指针偏移和类型断言，没有中间抽象层。
-
ptr不是数据地址，而是“可解引用的起始地址”——对 slice，它是slice.header.Data；对 string，它是string.header.Data；对 interface{}，它指向底层数据，而非 iface 结构体本身 -
flag编码了是否可寻址、是否是间接引用、是否是嵌入字段等状态，用位运算组合，比如flagIndir表示需再解一次指针才能拿到值 -
Interface()方法必须检查flag中的flagSafe位，否则 panic：“reflect: call of Value.Interface on zero Value” 就是flag为 0 导致的
真正该盯住的三个文件，而不是整个 reflect 目录
全目录 1 万行代码里，95% 是包装、校验和边界处理；核心机制集中在以下三处：
立即学习“go语言免费学习笔记（深入）”；
-
runtime/type.go：定义_type、uncommonType、method等结构，字段顺序与编译器输出严格对应，改一个字段偏移就崩 -
reflect/type.go：把runtime._type转成reflect.Type接口，关键在toType函数，它只是做指针类型转换，不复制数据 -
reflect/value.go：重点看packEface/unpackEface、valueInterface、以及所有get/set方法的前几行——它们都在做ptr偏移 +typ校验
想靠读源码搞懂 reflect，最有效的动作不是“通读”，而是用 go tool compile -S 看一段反射调用生成的汇编，对照着 runtime/type.go 里的结构体字段偏移去验证。否则，你看到的全是“为什么这里要 &^ flagRO”、“为什么这个 uintptr 要右移 3 位”，答案永远在编译器和 runtime 的契约里，不在 reflect 包本身。
