必须用 uintptr(unsafe.Pointer(t)) 作 map key，因 reflect.Type 不可比较，字符串拼接不可靠；字段访问应预建索引查表，禁用 FieldByName；热路径宜用 unsafe.Offsetof 生成闭包，零反射开销。
缓存 reflect.Type 时必须用 uintptr(unsafe.Pointer(t)) 当 key，其他方式不是慢就是错
为什么不能用 reflect.TypeOf(x) 直接当 map key
Go 的 reflect.Type 类型不可比较，编译器会直接报 invalid map key type。有人退而求其次用 t.String() 或 t.PkgPath() + "." + t.Name() 拼字符串，结果发现：匿名 struct 返回空字符串、vendor 多版本下包路径冲突、每次拼接还触发 GC 分配。这些都不是“有点慢”，而是根本不可靠。
-
uintptr(unsafe.Pointer(t))是唯一零开销、稳定、标准库实测可行的方式 - 它取的是 runtime 内部类型元数据的地址，整个程序生命周期内不变
- 别写
unsafe.Pointer(&t)——那是栈上变量地址，每次调用都不同
字段访问别碰 FieldByName，预建索引查表才是正解
FieldByName 是线性搜索：10 字段比 10 次，100 字段比 100 次，且每次都要做字符串比对。它根本不适合热路径。你应该在首次访问某类型时，一次性遍历所有字段，构建 map[string]int（字段名 → 索引），后续直接 fields["Name"] 查下标。
- 缓存结构建议是
type fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，不是裸的[]reflect.StructField - key 用
uintptr(unsafe.Pointer(t))，value 存这个预计算好的结构体 - 别用
sync.Map存字段索引映射——读多写少场景下，普通map+sync.RWMutex更快
热路径彻底绕过反射：用 unsafe.Offsetof 生成闭包
缓存只是减少开销，真正零反射成本的做法，是在初始化阶段算出字段偏移，封装成纯函数闭包。比如对 User.Name，提前算出 offset := unsafe.Offsetof(User{}.Name)，再写：
立即学习“go语言免费学习笔记（深入）”；
func getName(u *User) string {
return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + offset))
}
这个函数运行时不走任何反射逻辑，没有接口转换、没有 GC 分配，实测比缓存反射快 5–10 倍。
- 前提：输入必须是指针，且结构体字段顺序和类型不能变（加字段到中间就失效）
- 别在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存 - 这种闭包只能用于明确性能瓶颈点，不是通用方案；字段重排、
//go:notinheap标记都会让它崩溃
最容易被忽略的一点：缓存不是越早越好，而是越懒越好。类型信息只在第一次真正需要时解析，而不是启动时全量加载。字段偏移这种东西，一旦结构体布局变化，缓存就变成定时炸弹——它不报错，只是悄悄返回错误值。
