真正慢的是FieldByName、MethodByName、Call、Interface()等后续操作；缓存应针对字段名→索引或方法名→Method，用uintptr(unsafe.Pointer(t))作key，懒加载优于init预热。
reflect.ValueOf 和 reflect.TypeOf 本身不慢，慢在后续操作
很多人一看到“反射慢”就下意识缓存 reflect.Value，结果发现毫无改善——因为 reflect.ValueOf 和 reflect.TypeOf 只是拿到指针并做一次类型查表，开销极小（纳秒级）。真正吃性能的是：FieldByName、MethodByName、Call、Interface() 这些后续调用。
它们的问题很实在：
-
FieldByName是线性遍历所有字段做字符串比较，100 字段的 struct 就要比 100 次 -
MethodByName先哈希再遍历方法表，还要校验参数签名、构建栈帧 -
Interface()触发接口值构造，产生额外 GC 分配和指针拷贝 - 每次
reflect.Value都是新分配的结构体，不可比较、不可复用
用 uintptr(unsafe.Pointer(t)) 做 type 缓存 key 才可靠
想缓存类型元信息？别用 t.String() 或 t.PkgPath() + "." + t.Name() 当 map key。前者对匿名 struct 失效；后者在 vendoring、多模块共存或重命名包时会冲突。
Go 标准库（如 encoding/json）的真实做法是：
立即学习“go语言免费学习笔记（深入）”；
- 把
reflect.Type转成底层*abi.Type，再取其地址转为uintptr - 用
uintptr(unsafe.Pointer(t))作 map key —— 零分配、零字符串拼接、跨编译单元稳定 - 缓存内容推荐是
map[string]int（字段名→索引）或map[string]reflect.Method（方法名→Method对象） - 别用
sync.Map存这个映射：读多写少场景下，它比map+sync.RWMutex更慢
字段访问彻底绕过反射：unsafe.Offsetof + 闭包生成
这是实测提升 5–10 倍、GC 分配趋近于零的方案。核心思路是：把“运行时猜字段在哪”变成“编译期记住偏移量”。
例如对 User.Name：
- 在
init()中用unsafe.Offsetof(User{}.Name)算出偏移量 - 封装成纯函数闭包：
func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 输入必须是指针（可寻址），且结构体字段顺序/类型不能变（否则 offset 失效）
- 加
//go:build !race注释，否则 race detector 会报错
这种写法已广泛用于 msgpack、gogoprotobuf 等高性能序列化库。
别在 init() 里预热所有类型，懒加载才是关键
最容易被忽略的一点：不要在 init() 函数里一次性预计算所有可能用到的类型信息。你根本不知道哪些会被实际用到，纯属浪费内存和启动时间。
正确做法是按需加载：
- 首次访问某类型时触发计算，填入全局缓存
- 用
sync.Once或 CAS 控制初始化竞态 - 如果类型范围已知（比如只处理
User、Order、Payment），才考虑预热；否则一律懒构造
汇编级优化在这里没有意义——Go 的 abi.Type 布局虽稳定，但直接手写汇编无法绕过 Go 的内存模型约束和 GC 标记逻辑。所谓“黑科技”，本质是更早地把运行时工作移到初始化阶段，并用 unsafe 把类型系统信任链从反射层下移到 runtime 层。这已经是最接近极致的路径了。
