Go反射在高频路径上会严重拖垮内存和CPU——reflect.ValueOf每次调用都堆分配约96字节结构体，FieldByName触发线性字符串比对与额外分配，GC压力随请求量线性增长。
Go 反射不是“慢一点”，而是会在高频路径上直接把内存和 CPU 一起拖垮——reflect.ValueOf 每次调用都分配新对象，FieldByName 触发字符串比对和堆分配，GC 压力会随请求量线性上涨。
为什么 reflect.ValueOf 一进循环就崩内存
它不只是“取个值”，而是构造一个带标志位、间接指针、类型引用的完整结构体（约 96 字节），且每次都是新堆分配：
- 传入大 struct 或 slice 时，
reflect.ValueOf会触发 interface{} 装箱，再拷贝一份数据到堆上 - 在 HTTP handler 或消息解包循环里每请求调一次，等于每请求多分配一次 + GC 扫描一次
-
reflect.ValueOf(nil)不 panic，但后续.Kind()或.Type()会 panic，且错误无行号信息 - 实测：10 万次
reflect.ValueOf(&s)分配量是缓存后FieldByIndex路径的 4.2 倍（go test -benchmem）
FieldByName 比字符串查找还贵
它不是哈希查表，而是对结构体所有字段名做 == 比较，字段越多越慢，且每次都要重新遍历：
- 10 字段结构体 → 平均 5 次字符串比对；100 字段 → 平均 50 次；每次比对都涉及内存读取和可能的 alloc
- 字段名字符串本身也被反射内部持有，无法被 GC 回收，长期驻留堆上
- 正确做法是启动时用
t := reflect.TypeOf(T{})预扫描，构建map[string]int缓存字段索引，之后全用v.FieldByIndex([]int{idx}) - 别用
map[interface{}]T缓存类型——interface{}作 key 无法命中，因底层含 typeptr+dataptr 两部分
缓存什么、怎么缓存才真正省事
缓存目标必须是只读、全局唯一、可安全并发访问的对象：
立即学习“go语言免费学习笔记（深入）”；
- 该缓存：
reflect.Type（地址恒定）、字段名→索引映射、reflect.Method实例 - 不该缓存：
reflect.Value（绑定具体实例，无法复用）、interface{}或string做 key（开销大或不准确） - 轻量方案：全局
var typeCache = sync.OnceValues(map[uintptr]fieldMap{})，key 用uintptr(unsafe.Pointer(t.UnsafePointer())) - 更稳方案：用
sync.Map[reflect.Type]fieldMap，但注意sync.Map的原子操作在纯读场景反而略重，首次初始化用sync.Once更合适 - 终极省事：预生成闭包函数，比如
func(v interface{}) int64 { return v.(*MyStruct).ID }，完全绕过反射
真正难的不是写对 reflect.Value.Elem().SetInt()，而是意识到：当你要为 3 个固定 struct 写判空逻辑时，反射不是“灵活”，是给自己埋了一个 runtime panic + GC 毛刺的坑。
