反射调用比直接调用慢多少
慢 5–50 倍，取决于操作类型。调用 reflect.Value.Call 执行方法时通常慢 20–50 倍；仅读取字段（reflect.Value.Field）或获取类型信息（reflect.TypeOf）则慢 5–10 倍。这不是理论值，而是实测中在 Go 1.20+ 下常见范围。
原因很实在：反射要绕过编译期绑定，每次都要查类型系统、做类型检查、构造调用栈帧、处理接口转换。这些动作无法内联，也无法被编译器优化掉。
- 简单字段访问（如
v.Field(0).Int()）比直接obj.ID慢约 7 倍 -
reflect.Value.MethodByName("Foo").Call([]reflect.Value{})比obj.Foo()慢约 35 倍 -
reflect.TypeOf(x)和reflect.ValueOf(x)本身开销不大（纳秒级），但它们是后续高开销操作的“入场券”
哪些反射操作能被编译器部分优化
几乎没有。Go 的反射设计就是运行时行为，所有 reflect 包函数都明确不参与编译期优化。但有两个例外场景，实际效果接近“半优化”：
- 当
reflect.Value来自已知具体类型且未逃逸（比如局部变量传入reflect.ValueOf），某些字段访问可能被 CPU 分支预测缓存加速，但不改变量级差异 -
reflect.StructField.Offset在 struct 类型固定时可提前算出，但你得自己缓存——标准库不做这事
别指望 go build -gcflags="-m" 显示“inlined”，它不会。反射调用永远标记为 cannot inline: function has reflect.Value in signature 或类似提示。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
如何安全地缓存反射结果避免重复开销
缓存 reflect.Type 和 reflect.Value 的结构信息（如字段索引、方法指针）能省下 30%–60% 的重复成本，但必须手动做，且要注意生命周期。
- 用
sync.Map缓存reflect.Type→ 字段名到reflect.StructField的映射，而不是每次调用都t.FieldByName - 对高频调用的方法，提前用
t.MethodByName获取reflect.Method并存为函数变量，避免每次重查 - 切忌缓存
reflect.Value实例（如reflect.ValueOf(ptr)），它绑定了具体数据地址，容易导致内存泄漏或 panic（如原对象被 GC） - 缓存键推荐用
t.String()或fmt.Sprintf("%s.%s", t.PkgPath(), t.Name())，不用unsafe.Pointer(t)—— 类型可能被重复定义，地址不可靠
什么情况下必须用反射且值得承担开销
不是“想泛化就上反射”，而是只有三类场景真正绕不开：序列化/反序列化（如 json.Marshal）、依赖注入容器（如 wire 不介入时的手写 DI）、以及通用 ORM 的字段映射（如 sqlx 解析 struct tag）。其他多数情况，接口 + 类型断言更轻量、更安全。
- 如果你只是想“根据字符串名调用方法”，先考虑 map[string]func() 或者 interface{} + switch
- 如果是为了“遍历 struct 字段生成日志”，
fmt.Printf("%+v")或sprintf配合自定义String()方法往往更快更稳 - 错误信息里出现
reflect.Value.Interface: cannot return value obtained from unexported field就说明你已经踩进权限坑了——反射不能碰小写字段，而普通调用可以，这个限制本身就在提醒你：这里不该用反射
最常被忽略的一点：反射代码一旦进入 hot path（比如 HTTP handler 内部每请求都反射），pprof 里 reflect.* 占比会突然跳到 40% 以上。这时候不是优化反射，是该砍掉它。
