reflect.typeof和reflect.valueof调用吃内存，因每次需装箱interface{}、查类型哈希表、构造新实例；reflect.valueof对结构体平均分配128–256字节且多逃逸至堆，fieldbyname为线性字符串比对，非o(1)查表。
reflect.TypeOf 和 reflect.ValueOf 为什么一调就吃内存
每次调用 reflect.TypeOf 或 reflect.ValueOf 都不是“取个元信息”那么简单——它要查全局类型哈希表 runtime.types，把原始值装箱进 interface{}（触发堆分配），再构造新的 reflect.Type 或 reflect.Value 实例。结构体越大、slice 越长，装箱开销越明显。
- 对一个含 3 个 string 字段的 struct，
reflect.ValueOf平均分配 128–256 字节，且多数逃逸到堆上 -
reflect.TypeOf虽不拷贝数据，但首次访问该类型时仍需解析方法集和字段树，后续调用才复用缓存 - 在 HTTP handler 中每请求都调一次
reflect.ValueOf(req)，pprof 里会看到runtime.mallocgc占比飙升
FieldByName 是线性搜索，不是 O(1) 查表
reflect.Value.FieldByName 在字段数超过 10 个时，性能断崖式下跌。它内部是字符串逐字段比对，没哈希预处理，20 字段的 struct 平均要比较 10 次才能命中。
- 别在循环里反复调
FieldByName("ID")；改用v.Field(i)，并在注释里写明索引含义，比如// ID at index 0 - 字段名稳定时，启动时预计算
map[string]int映射，存在sync.Map里，后续查表是 O(1) - 避免缓存
reflect.Value实例（含具体值），只缓存reflect.Type和[]int字段偏移数组——后者更轻、GC 友好
reflect.Value.Call 慢得离谱，不是“写法问题”而是机制缺陷
reflect.Value.Call 的慢不是能靠“少传几个参数”优化的。它每次都要重做编译期已知的事：校验参数类型、分配临时切片装 reflect.Value、拆包接口、跳转函数指针、再打包返回值。空函数直调约 2 ns，而 Call 通常 20–200 ns。
- 热路径（如 RPC 解包、JSON unmarshal 内部）禁用
Call，哪怕只调一次 - 必须动态调用时，提前缓存
v.Method(i).Func得到函数指针，后续直接调闭包：fn := v.Method(0).Func; fn.Call(args) -
MethodByName自身也有哈希查找开销，不如Method(i)稳定；但前提是方法顺序不能变（比如加新方法不能插在中间）
真正难绕开反射的地方，得靠采样和降级控制
像 deep copy 任意 struct、调试时 dump interface{}、插件系统加载未知类型——这些场景反射是刚性需求，没法用泛型或接口替代。
- 只在 debug 模式启用 dump 逻辑，生产环境默认关闭
- 加采样率控制，比如
if rand.Intn(100) == 0 { dumpWithReflect(v) } - 限制输入规模：对嵌套深度 > 5 或字段总数 > 50 的值，直接返回 error 或截断，防止栈溢出或 OOM
反射不是 bug，但它是运行时开销的显性开关。最常被忽略的是：缓存 reflect.Type 能救 90% 的性能，但没人检查缓存 key 是否真能命中——用 interface{} 当 map key 就永远缓存失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
