应优先避免反射，必要时用FieldByIndex替代FieldByName、缓存reflect.Type、用unsafe.Offsetof跳过反射。高频场景下反射开销显著，泛型或代码生成更优。
用 FieldByIndex 替代 FieldByName
FieldByName 每次都做字符串比对，字段越多越慢——10 个字段就要比 10 次，嵌套结构体还会叠加。而 FieldByIndex 是 O(1) 查表，只要提前把字段名映射成索引，后续遍历就完全绕过字符串操作。
常见错误是把 map[string]int 缓存在函数内或局部变量里，导致每次调用都重新查；正确做法是在包级或类型初始化时预热：
- 用
sync.Map或普通map[reflect.Type]map[string]int存字段名→索引映射 - 首次访问某类型时调用
t.FieldByName("Name")获取StructField.Index，存下来复用 - 避免在循环里反复调用
t.FieldByName，哪怕只查一次也浪费
缓存 reflect.Type 和 reflect.Value 的构造开销
reflect.TypeOf 和 reflect.ValueOf 看似轻量，但每次调用都会触发堆分配（reflect.Value 内部约 96 字节），且 interface{} 拆包过程有逃逸风险。高频场景下 GC 压力会明显上升。
实测显示，对同一类型反复调用 reflect.ValueOf(x)，比缓存一个 reflect.Type + 手动构造 reflect.Value 慢 3–5 倍：
- 把
reflect.TypeOf(T{})提前存为包级变量，别在函数里重复算 - 如果输入总是同一种指针类型（如
*User），可用reflect.New(t).Elem()复用 Value 模板 - 注意：
reflect.ValueOf传值会导致拷贝，传指针才能修改原值；但传指针本身不解决分配问题
用 unsafe.Offsetof 避免反射对象创建
当字段顺序稳定、结构体不加/删字段、也不改 tag 影响对齐时，unsafe.Offsetof(User{}.Name) 能直接拿到内存偏移，后续用指针运算读写，性能接近原生访问，彻底跳过 reflect.Value 构造和字段查找。
这不是通用优化，而是手术刀式处理热路径：
- 必须确保字段是 exported，且结构体没加
//go:notinheap或其他内存约束 - 闭包里封装 getter/setter 时，参数必须是
*User，不能是interface{}，否则又引入接口逃逸 - CI 中要校验结构体变更后 offset 是否失效，比如加字段到中间就会让后续所有 offset 偏移错位
该不该用反射，比怎么优化更重要
很多场景下，反射不是“慢得需要优化”，而是“根本不该出现”。比如校验函数、序列化入口、ORM 参数绑定——这些地方一旦成为压测瓶颈，优先考虑泛型或 go:generate 生成专用代码，而不是堆砌缓存和 offset 技巧。
真正难的不是让反射变快，而是识别出：这个字段遍历，是不是本可以用 type User struct{...} + 手写逻辑替代？是不是已经因为追求“通用”而把简单问题复杂化了？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
