fieldbyname 是 o(n) 线性搜索而非 o(1) 哈希查找，每次调用需逐字段比对名称并执行多重运行时校验，嵌套访问开销剧增，且缓存易因结构体布局变动导致静默错误。
FieldByName 是线性搜索，不是哈希查找
每次调用 reflect.Value.FieldByName("Name") 都会从结构体第一个字段开始逐个比对名字，直到匹配或遍历完。这不是 O(1) 查表，而是 O(n) 字符串比较——20 字段的 struct 平均要比较 10 次，字段越多、嵌套越深，耗时越明显。
常见错误是把它放在 HTTP handler 或数据库批量写入循环里，单次请求触发几百次 FieldByName，CPU 时间直接被吃掉一大块。
- 字符串比较本身开销不小，尤其含 Unicode 时
- 每次比较都要检查字段是否 exported（首字母大写），额外分支判断
- 无法被 CPU 分支预测器有效优化，cache miss 率高
reflect.Value 包装带来接口逃逸和 GC 压力
把一个 struct{} 传给 reflect.ValueOf()，会触发一次接口值构造：底层是两个机器字（type pointer + data pointer）的拷贝。高频调用时，这些临时 reflect.Value 实例会快速填满 young generation，推高 GC 频率。
更隐蔽的问题是：一旦你对 reflect.Value 调用 .Addr() 或 .Interface()，它很可能逃逸到堆上——哪怕原 struct 本该在栈上分配。
- 避免在热路径中反复调用
reflect.ValueOf(x)，能缓存reflect.Type就别缓存reflect.Value - 传指针而非值：
reflect.ValueOf(&u)比reflect.ValueOf(u)少一次内存拷贝 - 别把
reflect.Value存进 map 或 slice，它不是轻量对象
字段访问链路长，每步都带校验开销
想读一个嵌套字段 u.Profile.Address.City，用反射就得走：v.Field(0).Field(0).Field(0) 或 v.FieldByName("Profile").FieldByName("Address").FieldByName("City")。每层调用都要做：
- 检查
reflect.Value是否 valid - 检查是否 addressable（尤其
Field()对不可寻址值 panic） - 检查索引是否越界（
Field(i)）或名字是否存在（FieldByName） - 构造新的
reflect.Value实例并填充字段信息
这些校验在编译期已知、运行时纯属冗余。4 层嵌套下来，光校验就占了 70%+ 时间，真正读内存的指令反而成了配角。
结构体布局变动会让所有缓存失效
有人尝试“缓存字段名 → 索引映射”，比如用 sync.Map 存 map[string]int{"Name": 1}。这确实把查找降到 O(1)，但有个硬伤：只要结构体加字段、删字段、改字段顺序，或者调整 json: tag 导致内存对齐变化，索引就全错——程序不 panic，但读到的是别的字段，结果静默错误。
这也是为什么偏移量方案（unsafe.Offsetof）虽然快，却只适合 DB 模型这类字段极少变动的场景。你得和编译器达成共识：这个 struct 的内存布局就是稳定的，否则 runtime crash 只是时间问题。
