不能在循环里调用 reflect.typeof，因其每次调用均需查全局类型表、分配 reflect.rtype 实例、触发接口解包和 gc，导致 cpu 与内存开销激增，且阻止函数内联；应缓存 uintptr(unsafe.pointer(reflect.typeof(x))) 并复用字段索引等元数据。
因为每次调用 reflect.TypeOf 都会触发运行时类型查表、分配临时结构体、绕过编译期优化，高频使用直接抬高 CPU 和 GC 压力。
为什么不能在循环里调用 reflect.TypeOf
它不是“查个类型”那么简单：每次调用都要从接口值中提取类型元数据指针，再查 runtime 的全局类型表，最后 new 一个 reflect.rtype 实例（哪怕类型完全相同）。实测在热路径每秒调用 10 万次，比缓存后慢 3–5 倍，且堆上多分配数 MB 内存。
- 字段多、嵌套深的 struct，解析开销呈线性增长
- 若参数是
interface{}，还要额外做接口头解包，触发一次小 GC - 哪怕只写一行
reflect.TypeOf(v)，也会让编译器放弃对所在函数内联（go tool compile -l -m=2显示cannot inline: contains call to reflect.TypeOf）
reflect.TypeOf 的正确缓存方式
缓存目标必须是 reflect.Type 本身，而不是它的字符串表示或接口值；key 必须稳定、零分配、能跨 goroutine 复用。
- ✅ 正确 key：
uintptr(unsafe.Pointer(t))，其中t = reflect.TypeOf(x)—— Go 运行时保证同一类型的t地址恒定，且该指针指向只读元数据，不会被 GC 移动 - ❌ 错误 key：
map[interface{}]T（接口底层含值指针，不同变量无法命中）、map[string]T（t.String()触发字符串分配+哈希，匿名 struct 返回空串） - 不用
sync.Map：纯读场景下，普通map[uintptr]T+sync.Once初始化更轻量；sync.Map的原子操作反而拖慢查表速度
哪些地方最容易漏掉缓存
开发者常以为“只调一次就没事”，但实际很多框架逻辑会在每次请求、每个消息、每个字段映射时重复触发 —— 这些才是真正的高频点。
- HTTP 请求体反序列化（如
json.Unmarshal内部对每个 struct 类型反复调用reflect.TypeOf） - ORM 字段扫描：每条 SQL 查询结果都走一遍结构体反射，而非按类型预热
- 日志字段提取、指标打点等中间件，对入参类型做运行时判断
- 误把
reflect.ValueOf(&x).Type()当缓存——这仍是新分配的reflect.Value，没解决根本问题
最易被忽略的是：缓存了 reflect.Type，却没顺带缓存它的字段索引、方法表、tag 解析结果。真正省下的不是那一两次 reflect.TypeOf 调用，而是后续所有 FieldByName、MethodByName、NumField 的连带开销。字段偏移量一旦算出，就能用 unsafe.Pointer 直接访问，彻底退出反射路径。
