Go反射性能差因每次调用都强制走无法内联、必堆分配的路径：FieldByName线性搜索字段，Call开销达20–200ns，Interface()等触发逃逸，GC压力上升；应缓存Type和字段偏移而非Value。
Go反射导致性能变差不是“偶尔慢一点”，而是每次调用都强制走一条无法内联、无法编译期优化、必然触发堆分配的路径——它把本该在编译时确定的事，全堆给运行时去查表、比对、校验、打包。
reflect.Value.FieldByName 是线性搜索，不是哈希查找
字段名查找不走哈希表，而是遍历 reflect.StructField 列表逐个比对字符串。一个含 15 个导出字段的 struct，平均要比较 7–8 次才能命中；若字段名拼错或大小写不一致（比如传 "name" 但实际是 "Name"），它直接返回零值且不 panic，埋下静默 bug。
- 每调用一次
FieldByName，都新建一个reflect.Value，触发堆分配 - 无法被编译器内联，每次都是完整函数调用开销
- 字段越多，耗时越接近 O(n)，且常驻 GC 压力上升
reflect.Value.Call 的固定开销高达 20–200 ns
reflect.Value.Call 不是“动态跳转”那么简单，它每次都要：校验所有参数类型、分配临时切片装 reflect.Value、拆包接口、跳转函数指针、再打包返回值——而直调同函数仅需约 2 ns。
- 热路径（如 HTTP handler、高频循环）中调用一次，就等于主动引入 10–100 倍延迟
-
MethodByName还额外多一层哈希查找，不如Method(i)稳定（但要求方法顺序不变） - 缓存
v.Method(0).Func成函数指针后复用，能绕过大部分开销
reflect.ValueOf 和 reflect.TypeOf 触发接口转换与元数据查找
这两个看似轻量的函数，实则每次都会触发接口隐式转换、从 runtime 类型表中提取元数据，且结果不可复用——reflect.Value 绑定了具体实例，不能跨值缓存；只有 reflect.Type 和字段偏移数组（[]int）值得存。
立即学习“go语言免费学习笔记（深入）”；
- 传入
nil指针时，reflect.ValueOf(nil)返回零值，但后续调.Kind()或.Type()会 panic，必须先.IsValid() - 对
interface{}调用reflect.TypeOf，返回的是底层实际类型（如*MyStruct），不是interface{}本身 - 缓存应使用
sync.Map存reflect.Type→ 字段索引映射，避免锁竞争
反射让逃逸分析失效，间接推高 GC 压力
反射操作常导致本可栈分配的变量被迫逃逸到堆上，尤其当涉及 Interface()、Call() 或嵌套结构体遍历时。压测中常见 QPS 下降 20%–40%，GC pause 明显拉长。
-
reflect.Value.Interface()是重灾区：它必须构造新接口值，触发分配 - 字段访问尽量用
v.Field(i)+ 预计算索引，而非反复FieldByName - 真正难处理的是 debug dump、deep copy 任意 interface{}、插件加载等刚性需求场景——这些地方只能接受代价，并严格限频、限深、限规模
最易被忽略的一点：缓存本身不是目的，关键是缓存什么。缓存 reflect.Value 实例毫无意义，它绑定了具体数据；只缓存 reflect.Type 和字段偏移数组，才能真正把 O(n) 降到 O(1)，且不增加 GC 负担。
