Go反射中reflect.ValueOf/TypeOf必然触发堆分配，因需将值装箱为interface{}并构造reflect.Value实例，即使仅取.Kind()也无法避免；实测64字节结构体调用即分配约128字节，且该分配不显示在用户函数逃逸分析中。
Go反射在每次调用 reflect.ValueOf 或 reflect.TypeOf 时，几乎必然触发堆分配，这是高频路径下性能崩塌的起点。
为什么 reflect.ValueOf 一调就分配内存
它不是“读个类型”那么简单，而是要完成一整套运行时打包动作：
- 把原始值装箱进
interface{}—— 这一步对非接口类型（如int、struct{}）会强制触发一次堆分配 - 构造新的
reflect.Value实例，内部包含标志位、指针、类型引用等字段，本身也占堆空间 - 若传入的是大结构体或 slice，装箱开销直接随数据大小线性增长
- 编译器无法优化掉这个分配：哪怕你只取
.Kind()后立刻丢弃，分配已发生
实测中，一个 64 字节结构体调用 reflect.ValueOf，会在 heap profile 中稳定出现一次 ~128 字节的分配（含 header 开销）。
逃逸分析里看不见但真实存在的分配热点
很多开发者用 go build -gcflags="-m" 检查逃逸，却漏掉了反射自身的分配 —— 因为它是 reflect 包内部做的，不体现在你的函数逃逸报告里。
立即学习“go语言免费学习笔记（深入）”；
-
json.Marshal、encoding/gob底层大量调用reflect.Value.Interface()，每次都会逃逸到堆 - ORM 字段映射循环中写
v.Field(i).Interface()，等于每字段都新分配一次 interface{} 值 - 校验库遍历结构体字段时用
v.Field(j).Addr().Interface()，不仅分配，还可能因地址取值失败 panic
这类分配在 pprof heap 图里表现为 runtime.convT2I 或 reflect.valueInterface 占比极高，但函数名不暴露业务逻辑，容易被忽略。
缓存 reflect.Type 和字段索引能省掉什么
类型元信息是全局只读的，重复解析纯属浪费。缓存后，后续访问可压到纳秒级，但要注意边界：
- 缓存
reflect.Type本身不解决reflect.ValueOf分配问题，它只省掉哈希表查找和类型构造开销 - 字段名转索引（如
type.FieldByName("ID")）必须缓存，否则每次字符串比对 + 遍历都是 O(n) 开销 - 推荐方式：用
sync.Once初始化map[reflect.Type]struct{ ID int; Name string }，避免并发读写锁 - 切忌缓存
reflect.Value—— 它绑定了具体值的生命周期，复用会导致数据污染或 panic
真正关键的不是“要不要缓存”，而是得意识到：第一次解析慢是常态，但之后还慢，一定是没缓存字段索引或误用了 Value。
哪些写法看似省事，实际让 GC 更喘不过气
这些模式在日志、中间件、配置绑定里高频出现，但代价极重：
- 在 HTTP handler 里对每个请求做
reflect.ValueOf(req).FieldByName("Header").Interface()—— 每次请求至少 3–5 次堆分配 - 用
map[string]interface{}接收 JSON 后再反射转 struct，等于双重分配（先转 map，再反射赋值） - 测试断言里写
assert.Equal(t, got, want)，而got是大结构体 —— testify 内部用反射深比对，分配爆炸 - 泛型能覆盖的场景硬上反射，比如
func MapKeys[K comparable, V any](m map[K]V) []K，比反射提取 key 快 20 倍且零分配
最隐蔽的坑是：单次分配看起来微不足道，但在 10k QPS 下，每请求多分配 128 字节，就是每秒 1.2 MB 堆压力 —— 一周后 GC PauseTotalNs 就会明显抬头。
