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，比任何经验都管用。
