Go反射性能差是设计使然：典型场景比直接调用慢10–100倍，字段访问慢20x、方法调用慢40x，且引发额外内存分配与GC压力；根本原因是绕过编译期检查、禁用内联、依赖运行时字符串查找与动态分派。
Go语言反射性能确实差——不是“略慢”，而是典型场景下比直接调用慢 10–100 倍，字段访问慢约 20x，方法调用慢约 40x，且伴随额外内存分配（如 32 B/op）和 GC 压力。这不是配置问题，是设计使然：反射绕过编译期类型检查、禁用内联、依赖运行时字符串查找与动态分派。
为什么 reflect.ValueOf 和 reflect.TypeOf 一调就慢？
每次调用都触发完整类型解析：遍历结构体字段、提取 tag、构建内部元数据表。哪怕对同一个 struct 重复调用 1000 次，也重复做 1000 次解析，而非复用。
- 避免在循环或 HTTP 请求处理主路径中写
reflect.ValueOf(req).Elem().FieldByName("ID") - 缓存结果比“省几行代码”重要得多：用
sync.Map或包级变量存reflect.Type和预计算的字段索引映射 - 字段名查找（
FieldByName）是线性搜索，复杂度O(n)；换成Field(i)索引访问，直接O(1)
缓存 reflect.Type 和字段索引真的有效吗？
非常有效。实测可将结构体序列化热路径提速 5–10 倍。关键是把“解析”挪到初始化阶段，运行时只查表。
var typeCache sync.Map // map[reflect.Type]map[string]int
func getFieldIndex(t reflect.Type, name string) int {
if cache, ok := typeCache.Load(t); ok {
return cache.(map[string]int)[name]
}
indexes := make(map[string]int)
for i := 0; i < t.NumField(); i++ {
indexes[t.Field(i).Name] = i
}
typeCache.Store(t, indexes)
return indexes[name]
}
- 首次访问某结构体类型时构建索引，后续直接
getFieldIndex(t, "CreatedAt")拿到字段序号 - 别缓存
reflect.Value实例本身（它绑定具体值），但可缓存其Type()和字段偏移信息 - 若结构体带大量 tag（如
json:"user_id,string"），也建议一次性解析并缓存 tag 结果，避免每次重复field.Tag.Get("json")
有没有比缓存更彻底的优化？
有——用代码生成替代运行时反射。这不是“未来可选”，而是高并发服务的标配做法。
立即学习“go语言免费学习笔记（深入）”；
-
ent、sqlboiler、protoc-gen-go都走这条路：编译前生成类型专用的Scan/MarshalJSON函数，执行时零反射开销 - 自己写
//go:generate脚本也很轻量：读取 struct tag，输出SetXXX方法或校验函数，和手写性能一致 - 当类型集合有限（如仅处理
User、Order、Product），优先用switch x := v.(type)+ 类型断言，比reflect.ValueOf(v).Kind()快一个数量级
真正难的不是“知道要缓存”，而是判断哪条路径算“热路径”——比如 ORM 的 Scan、API 的参数绑定、日志字段提取，这些地方一旦用了反射又没缓存，性能瓶颈会来得又快又沉默。别等 p99 延迟飙升才回头翻 pprof 看 reflect.Value.FieldByName 占了 40% CPU 时间。
