应缓存 reflect.Type 的 uintptr(unsafe.Pointer(t)) 作 key，预计算字段索引或方法映射，避免 FieldByName/MethodByName；热路径优先用 unsafe.Offsetof 生成闭包实现零开销访问。
缓存 reflect.Type 用 uintptr(unsafe.Pointer(t)) 当 key
每次调用 reflect.TypeOf(x) 都会触发类型表查找和接口转换，虽不分配大对象，但高频下仍可观。关键是：同一类型的 reflect.Type 实例在全生命周期内地址恒定，可安全用于缓存，但不能直接当 map key（reflect.Type 不可比较）。
正确做法是把它的底层指针转成 uintptr：uintptr(unsafe.Pointer(t))。零开销、不拼字符串、不依赖包路径，标准库如 encoding/json 就这么干。
- 别用
t.String()—— 匿名 struct 返回空字符串，直接失效 - 别用
t.PkgPath() + "." + t.Name()—— vendoring 或多模块共存时，相同类型可能有不同路径前缀 - 别缓存
reflect.Value—— 它每次调用都新建，不可比较，当 key 必报错或永远不命中
字段访问绕过 FieldByName，改用预计算索引查表
reflect.Value.FieldByName("Name") 是线性遍历所有字段再做字符串比对，100 字段就要比 100 次；而 reflect.Value.Field(i) 是数组下标访问，O(1)。真正要缓存的不是字段值，而是“字段名 → 索引”的映射。
建议结构体首次被访问时，一次性构建 map[string]int 或更丰富的 fieldInfo 结构（含 Offset、Tag、IsExported），key 用 uintptr(unsafe.Pointer(t))，value 存索引或偏移。
立即学习“go语言免费学习笔记（深入）”；
- 别用
sync.Map存这个映射 —— 读多写少场景下，原子操作反而比普通map+sync.RWMutex慢 - 别在
init()里预热所有类型 —— 你根本不知道哪些会被用到，纯属内存浪费 - 字段重排（比如中间加字段）会让索引失效，但这是可控代价；字符串匹配失效却是 runtime panic
热路径彻底不用反射：用 unsafe.Offsetof 生成闭包
缓存只是“减损”，真正零开销的做法是在初始化阶段算出字段偏移，封装成纯函数闭包。运行时只做指针运算和类型转换，无反射、无接口、无 GC 分配。
例如对 User.Name：
var nameOffset = unsafe.Offsetof(User{}.Name)
func getName(u *User) string {
return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + nameOffset))
}
- 必须传指针，且确保结构体布局稳定（字段顺序、类型、对齐不变）
- 若字段是 unexported 或结构体加了
//go:notinheap，unsafe.Offsetof可能返回 0 或 panic - race detector 下需加
//go:build !race条件编译，否则报错
方法调用别反复 MethodByName，缓存 reflect.Method 实例
reflect.Value.MethodByName("Save") 每次都做哈希+遍历；而 reflect.Value.Type().Method(i) 返回的 reflect.Method 是只读常量，地址稳定，可安全缓存。
缓存 key 同样用 uintptr(unsafe.Pointer(t))，value 是 map[string]reflect.Method。注意：必须基于指针类型取方法集（reflect.TypeOf(&v).Elem()），否则找不到指针接收者方法。
- 别缓存
reflect.Value.Method(i)—— 它绑定了具体实例，无法复用 - 别用
interface{}当缓存 key —— 底层包含值指针和类型指针，不同变量即使类型相同也无法命中 - 真正瓶颈不在
Call()动作本身，而在每次调用前的 receiver 校验和参数转换；缓存reflect.Method能跳过前者，但后者仍存在
FieldByName 或 MethodByName。缓存只是起点，字段/方法访问方式不改，性能瓶颈照旧。 
