go反射开销巨大：reflect.Value.Call比直接调用慢50–100倍，FieldByName慢30–60倍；因需查类型哈希表、Interface{}装箱、堆分配及构造reflect.Value等，且禁用编译器优化；缓存type和字段信息可将后续访问降至纳秒级。
Go 的反射开销非常真实——在高频路径上，reflect.Value.Call 可能比直接函数调用慢 50–100 倍；reflect.Value.FieldByName 访问结构体字段，比直接点号访问慢 30–60 倍。这不是理论值，而是大量基准测试（go test -bench）反复验证过的量级。
为什么 reflect.typeof 和 reflect.ValueOf 一调就拖慢程序
它们不是“取个类型”那么简单，每次调用都要：
- 查全局类型哈希表（
runtime.types），涉及指针跳转和哈希计算 - 将原始值装箱进
interface{}，触发一次堆分配（尤其对大结构体或 slice） - 构造新的
reflect.Type或reflect.Value实例，其中Value内部还带额外的标志位和指针管理 - 绕过编译器所有优化：内联失效、逃逸分析受限、CPU 分支预测容易失败
比如你在 http 中间件里对每个请求都 reflect.ValueOf(req).MethodByName("Header")，那它就成了 CPU profile 里最亮的函数之一。
缓存 reflect.Type 和字段信息真能救命
类型元信息是只读且全局唯一的，重复解析纯属浪费。缓存后，首次解析耗时不变，但后续调用可降到纳秒级。
立即学习“go语言免费学习笔记（深入）”；
var typeCache sync.map // map[reflect.Type]*fieldInfo type fieldInfo struct { nameToIndex map[string]int fields []reflect.StructField } func getStructInfo(t reflect.Type) *fieldInfo { if cached, ok := typeCache.Load(t); ok { return cached.(*fieldInfo) } info := &fieldInfo{ nameToIndex: make(map[string]int), fields: make([]reflect.StructField, t.NumField()), } for i := 0; i < t.NumField(); i++ { f := t.Field(i) info.nameToIndex[f.Name] = i info.fields[i] = f } typeCache.Store(t, info) return info }注意坑点：sync.Map 在写少读多场景下表现好，但如果类型特别多（如每种数据库模型都不同），要考虑内存占用；另外别缓存 reflect.Value（它含可变状态），只缓存 Type 和解析后的静态结构。
什么时候该放弃反射，改用代码生成
如果你的反射逻辑是「固定模式 + 多种类型」，比如 jsON 序列化、DB 插入、gRPC 消息转换，那 runtime 反射就是错的选择。标准库 encoding/json 在 Go 1.19+ 已对常见类型做代码生成优化，第三方库如 easyjson、ffjson 或基于 go:generate 的自定义模板，能把反射路径完全移出热路径。
- 典型信号：你写了通用函数，但参数类型其实就那十几个结构体
- 生成时机：CI 构建阶段执行
go generate ./...，产出xxx_gen.go - 性能收益：序列化吞吐量常提升 3–5 倍，GC 压力显著下降
别低估维护成本：一个 go:generate 脚本可能比一堆反射逻辑更易读、更易调试、ide 补全也正常。
真正难的不是“要不要用反射”，而是判断它是否落在关键路径上——很多团队直到 pprof 看到 reflect.methodValueCall 占了 40% CPU 才意识到问题。上线前跑一次 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，比任何经验都管用。