Go反射性能差主因是未缓存类型信息和字段索引，且误复用reflect.Value；FieldByName线性查找、reflect.ValueOf重复分配导致GC压力大，缓存reflect.Type并用FieldByIndex或unsafe偏移可提升5–10倍性能。
反射本身不拖累性能，拖累的是没做类型缓存、字段索引预计算、以及错误地把 reflect.Value 当成可复用对象来反复调用 —— 尤其当结构体指针被反复传入 reflect.ValueOf 时，开销全在重复解析和临时分配上。
为什么 reflect.ValueOf(&s) 在循环里特别慢
每次调用都触发完整运行时类型查找、构建新 reflect.Value 实例、校验 receiver 可寻址性；哪怕 s 是同一地址的指针，reflect.ValueOf(&s) 仍会新建对象，无法复用。实测在 10 万次循环中，比缓存 reflect.Type 和预建字段索引慢 4 倍以上，GC 分配量翻倍。
- 别在 HTTP handler 或序列化热路径里写
v := reflect.ValueOf(&obj).Elem() - 应提前取
t := reflect.TypeOf(&obj).Elem()，再用uintptr(unsafe.Pointer(t))作 key 缓存字段映射 -
reflect.ValueOf(&obj)返回的是新实例，不能当 map key，也不能“省一次调用”而缓存它
FieldByName 是反射里最隐蔽的性能黑洞
它内部是线性遍历所有导出字段 + 字符串比较，字段越多越慢。一个 30 字段的 struct，v.FieldByName("CreatedAt") 比 v.Field(5) 慢 7–9 倍，且无法被编译器优化。
- 初始化阶段用
t.NumField()+t.Field(i)扫一遍，建map[string]int字段名到索引映射 - 字段名固定时直接硬编码索引，如
v.Field(0).Interface()，跳过全部字符串操作 - 别用
t.String()或t.Name()拼 key 缓存字段映射 —— 匿名 struct 不支持，vendoring 下还可能冲突
缓存 reflect.Type 时最容易踩的 key 错误
常见错误是把 interface{} 或 string 当 key：前者因接口头含值指针，不同变量即使类型相同也无法命中；后者引入字符串分配和哈希开销，且对匿名类型失效。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确 key：
uintptr(unsafe.Pointer(reflect.TypeOf(&s).Elem()))—— 零分配、地址唯一、标准库同款做法 - 错误 key：
map[interface{}]T（接口底层不相等）、map[string]T（t.String()对struct{X int}返回空字符串） - 别用
sync.Map存类型缓存 —— 读多写少场景下，普通map+sync.Once初始化更快更轻量
真正零开销的替代方案：unsafe 闭包不是噱头
当字段布局稳定（如 DB 模型），用 unsafe.Offsetof(User{}.Name) 算偏移，封装为 func(*User) string 闭包，运行时无反射、无接口转换、无 GC 分配。实测比缓存反射快 5–10 倍。
- 必须传指针，且确保结构体不会被 GC 移动（命名类型安全，但
interface{}接收需警惕） - 字段顺序变动、加字段、甚至启用
//go:build !no_unsafe都会让闭包崩溃 —— 它只适用于明确瓶颈点，不是通用解法 - 生成代码比运行时反射更稳：用
go:generate为热路径 struct 生成专属 marshal/unmarshal 函数，CI 中强制校验更新
最常被忽略的一点：性能损耗从来不在「用了反射」，而在「每次都要重做相同的事」—— 类型解析、字段查找、方法匹配，这些本可在初始化阶段做完。一旦开始在循环或高频请求路径里调 reflect.TypeOf，就已经输了。
