reflect.typeof 和 reflect.valueof 直接读取编译时生成的 _type 元数据，非动态推断；修改字段需满足可寻址性（如用 &s 后 elem()）；fieldbyname 因字符串遍历比 field(i) 慢百倍；主要开销在堆分配、类型校验和方法动态调用。
reflect.TypeOf 和 reflect.ValueOf 怎么拿到运行时类型信息
它们不“猜”类型，而是直接读取 Go 运行时已写死的 _type 元数据。每个编译后的类型（如 struct{A int}、[]string）在二进制里都有一份只读的 _type 结构体，记录尺寸、对齐、字段偏移、方法表指针等。当你调用 reflect.TypeOf(x)，底层只是把 x 所在 interface{} 的 eface._type 字段取出来，包装成 reflect.Type；reflect.ValueOf(x) 则同时提取 eface.data（值地址）和 _type，构造出可操作的 reflect.Value。
这意味着反射不是“动态推断”，而是“静态元数据的运行时暴露”。它快在查表，慢在绕过编译期优化路径。
为什么修改结构体字段会 panic：CanSet() 和可寻址性
反射不能随便改值——必须满足“可设置”（settable）条件，本质是要求底层值内存可写且能被寻址。常见错误包括：
-
reflect.ValueOf(someStruct).Field(0).SetInt(1)必然 panic：传入的是值拷贝，Field(0)返回的仍是不可寻址副本 - 正确写法是
reflect.ValueOf(&someStruct).Elem().Field(0).SetInt(1)：先取地址，再Elem()解引用到结构体本身，此时字段才可设置 - 即使字段名首字母大写（导出），若原始值不可寻址（比如字面量、函数返回值），
CanSet()仍返回 false
这个限制源于 Go 的内存模型：栈上临时值没有稳定地址，反射无法安全写入。
FieldByName 为什么比 Field(i) 慢 100 倍以上
Field(i) 是纯索引访问：结构体 _type 中字段信息以数组形式存储，i 直接当数组下标，O(1)。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
FieldByName(name) 则必须遍历整个字段数组，逐个比对 name 字符串，最坏 O(n)。实测在 20 字段结构体上，单次调用开销可达几百纳秒——高频循环中极易成为瓶颈。
缓解办法只有两个：
- 提前用
reflect.Type.FieldByName("Name")查一次，缓存Index，后续全用Field(i) - 或用
map[string]int手动建字段名到 index 的映射，避免每次重复遍历
反射带来的性能损耗到底在哪
主要三块硬开销：
-
reflect.ValueOf和Interface()触发堆分配：它们会把值复制到堆上（尤其大结构体），逃逸分析失效 - 所有
Value方法（Int()、String()、Interface()）都要做类型检查和边界校验，无法内联 - 方法调用（
Call()）需动态查方法表、构造参数切片、处理 recover，比直接调用慢 10–100 倍
真正危险的不是“慢”，而是这些开销在 profile 里藏得深：它不显式出现在你写的函数里，而是分散在 reflect 包内部，容易误判为“逻辑简单所以不该慢”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
