干净的反射性能基准测试需剥离初始化干扰：提前获取reflect.Value、用Field(i)代替FieldByName、循环前StopTimer/ResetTimer、传指针避免复制、禁用日志、关注allocs/op而非仅ns/op。
直接用 go test -bench 就行，但必须避开初始化干扰、禁用日志、控制逃逸，否则测出来的是垃圾数据。
怎么写一个干净的反射性能基准测试
核心是把“纯反射操作”从初始化、类型查找、堆分配等干扰中剥离出来。比如测结构体字段读取，不能每次循环都调 reflect.ValueOf 和 FieldByName——那测的是内存分配和字符串查找，不是字段访问本身。
- 提前调用
reflect.ValueOf(&s).Elem()获取可复用的reflect.Value，避免循环内重复构造 - 用
Field(i)代替FieldByName("Name")，跳过哈希查找和大小写匹配开销 - 在循环前加
b.StopTimer()→ 初始化 →b.ResetTimer()→ 进入循环，确保只计时核心逻辑 - 传值还是传指针？测字段读写优先传指针（
&s），否则reflect.ValueOf(s)会复制结构体，且无法 Set
常见错误：测出来的数字比手写代码慢 50 倍，其实是测错了
典型翻车现场：
- 在
for循环里反复调reflect.TypeOf(v)或reflect.ValueOf(v)：这会产生大量堆分配，pprof一看全是runtime.mallocgc - 用
Interface()把反射值转回interface{}：触发装箱，额外分配+类型断言 - 没关日志：
log.Printf在压测里能拖慢几十倍，必须log.SetOutput(io.Discard) - 结构体含
[]byte或嵌套 struct：反射遍历深度增加，性能衰减非线性，但你可能根本没意识到这是瓶颈点
对比测试必须控制变量
想搞清楚反射到底慢在哪，得横向拉出几组对照：
立即学习“go语言免费学习笔记（深入）”；
- 手写字段访问（
s.Name）作为 baseline - 反射 + 缓存
reflect.Type和字段索引（t.Field(0)） - 反射 + 每次都
FieldByName（模拟 tag 解析场景） - 如果涉及 JSON 解码，还要单独测
json.Unmarshal（它内部也用反射，但做了缓存）
运行命令建议加 -benchmem -cpuprofile=cpu.prof，用 go tool pprof cpu.prof 看热点是不是卡在 reflect.Value.Field 或 runtime.convT2I 上。
最容易被忽略的点：GC 压力不体现在 ns/op 里
ns/op 只告诉你单次耗时，但反射高频分配的 reflect.Value 会把对象扔到堆上，导致 GC 频繁触发。压测时间一长，Benchmark 的吞吐会掉，而 go test -benchmem 显示的 allocs/op 才是关键信号——如果这个值大于 0，说明你在制造 GC 垃圾。真正线上服务扛不住的，往往不是 CPU，而是 GC STW 时间。
