反射基准测试需禁用GC、关闭内联、报告分配，核心开销在reflect.ValueOf和Interface()的堆分配与类型检查，手写逻辑才是有效基线。
用 go test -bench 测反射函数，但必须禁用 GC 干扰
基准测试里不控制 GC，reflect.ValueOf 触发的堆分配会被 GC 周期掩盖，导致 B/op 和 ns/op 失真。真实开销藏在分配次数里，不是单纯看耗时。
- 加
-gcflags="-l"关闭内联（避免编译器优化掉反射调用，让测试更贴近生产） - 加
b.ReportAllocs()显式报告内存分配 - 用
b.ResetTimer()在初始化后才开始计时，排除 setup 开销 - 传值而非指针：若测试字段读取，用
ValidateWithReflect(s)（s是 struct 值），避免reflect.Value.Addr()额外开销
reflect.ValueOf 和 reflect.Value.Interface() 是主要开销点
单独调用 reflect.TypeOf 几乎没成本（纳秒级），但 reflect.ValueOf(x).Interface() 这一来回会触发堆分配 + 类型检查，小结构体上就多 50–100ns；若 x 是大 map 或嵌套 slice，Interface() 甚至会深拷贝，跳到微秒级。
- 实测一个 10 字段 struct 的遍历：原生字段访问约 2ns/字段，反射
v.Field(i).Interface()平均 180ns/字段 - 高频路径（如 HTTP 中间件每请求一次）会让 p99 延迟抬升 1–2ms
- 用
go tool compile -gcflags="-m" your_file.go看是否逃逸到反射路径，确认是不是真走reflect.Value
对比基线必须是手写逻辑，不能只比“另一个反射库”
很多人测 go-playground/validator vs reflect2，但真正该比的是：反射校验 vs 一个纯 if-else 手写函数。否则你永远不知道“反射”本身拖了多少后腿。
- 手写校验函数可被编译器内联，
reflect.Value.Field()永远不能 - 若结构体含
interface{}或未导出字段，手写函数还能控制 panic 行为，反射会直接崩 - 嵌套越深，反射衰减越剧烈——一个含 3 层嵌套的 struct，反射校验可能比手写慢 20 倍以上
别忽略 CanInterface() 和字段可见性带来的隐性开销
反射访问未导出字段（小写开头）时，v.Field(0).Interface() 会 panic。但很多人在 benchmark 里没加 if v.Field(i).CanInterface() 判断，导致测试中途崩溃或结果无效。
立即学习“go语言免费学习笔记（深入）”；
- 这个判断本身有开销，但比 panic 强；它本质是检查 flag 是否含
flagAddr和flagExported - 字段名查找（
v.FieldByName("Name")）比索引访问（v.Field(0)）慢 2–3 倍，因要哈希查表 - 对
nilinterface{} 调用reflect.ValueOf得到零值，后续.Kind()直接 panic，必须先.IsValid()
B/op。 
