Go反射在热点路径使单次操作从几纳秒升至上百纳秒，拖慢程序8–12倍，p99延迟跳升1–2ms；reflect.ValueOf/TypeOf触发堆分配、绕过编译优化；缓存Type/Value可省60%以上开销。
Go反射在热点路径上会拖慢程序 8–12 倍，不是“有点慢”，而是直接把单次操作从几纳秒拉到上百纳秒——这已经足以让 p99 延迟跳升 1–2ms。
reflect.ValueOf 和 reflect.TypeOf 是性能杀手源头
每次调用 reflect.ValueOf 或 reflect.TypeOf 都会触发一次堆分配：interface{} 拆包、构造 reflect.Value 结构体、拷贝底层数据指针和 flag 位。这不是“小开销”，而是强制绕过编译期优化的代价。
- 对一个 8 字段结构体做字段遍历，直接访问约
3ns，反射方式平均180ns+ -
reflect.Value.Interface()比直接类型断言慢 20–50 倍，且必然逃逸到堆 - 在 HTTP 中间件里对每个请求体做反射解析，CPU profile 里
reflect.Value.Field和reflect.Value.Kind几乎必排前三
基准测试必须控制变量，否则结果失真
用 go test -bench=. 测反射性能时，常见误判来自没压住干扰项：
- 不加
b.ReportAllocs()就看不到真实堆分配次数 - 传指针给
reflect.ValueOf（如reflect.ValueOf(&s)）会额外触发Addr()和Elem()，放大开销 - 没禁用 GC 干扰：加上
-gcflags="-l"关闭内联，更贴近线上真实行为 - 结构体含
[]byte或嵌套struct时，反射性能衰减呈指数级，但很多人只测 flat struct
缓存 Type/Value 能省掉 60% 以上重复开销
如果你必须用反射（比如写通用 JSON 编解码器），至少要把 reflect.Type 和首次构造的 reflect.Value 缓存下来：
- 全局 map 缓存
reflect.Type：键用t.String()或unsafe.Pointer(t)，避免每次reflect.TypeOf(x) - 对固定结构体类型，提前调用
reflect.ValueOf(&T{}).Elem()并缓存，后续用Set()替代反复构造 - 别缓存
reflect.ValueOf(fn)—— 函数值每次调用都可能变，缓存反而错；应缓存reflect.ValueOf(&fn).Elem()才安全
真正卡点不在“会不会用反射”，而在“有没有意识到每次 reflect.ValueOf 都在悄悄分配内存、逃逸、查表”。哪怕只多一层循环，开销就线性放大——这点容易被忽略，直到压测时 CPU 突然飙高。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
