应缓存reflect.Type而非反复调用reflect.TypeOf，因其需查表、分配内存并触发GC；同一类型返回地址恒定，可用uintptr(unsafe.Pointer(t))作key；字段访问应预建索引或用unsafe.Offsetof生成闭包实现零开销偏移访问。
直接缓存 reflect.Type，别让它在热路径上反复查表、分配、接口转换。
为什么每次 reflect.TypeOf 都慢得明显
它不是“取个类型”那么简单：要遍历运行时类型表找匹配项、分配新的 reflect.rtype 包装结构体、做接口转换、触发 GC 分配。实测在循环中每秒调用 10 万次，比缓存后慢 3–5 倍，B/op 翻倍。
- 同一类型的
reflect.TypeOf(x)返回值地址恒定，uintptr(unsafe.Pointer(t))可作 key，零开销 - 别用
t.String()或t.PkgPath() + "." + t.Name()：前者对匿名 struct 失效，后者在 vendoring 或多模块共存时可能冲突 - 禁止把
interface{}当 map key：底层含值指针+类型指针，不同变量即使类型相同也无法命中缓存 - 错误写法：
typeCache[reflect.TypeOf(x)] = data—— 编译报错：invalid map key type
字段访问别碰 FieldByName，预建索引映射才靠谱
FieldByName 是线性搜索：100 字段的 struct 就要比 100 次字符串。而 Field(i) 是数组下标访问，O(1)。高频字段读写必须绕过字符串比对。
- 缓存内容建议是
map[string]int（字段名→索引）或自定义fieldInfo结构，不是裸的[]reflect.StructField - key 推荐用
uintptr(unsafe.Pointer(t))，查出该类型的字段索引表后直接查表 - 别用
sync.Map存这个映射：读多写少场景下，它的原子操作比普通map+sync.RWMutex更慢 - 字段逻辑差异大（比如某些字段跳过、某些需解析 tag）时，可缓存到字段级，key 用
uintptr(unsafe.Pointer(&t)) + field.Name拼接
热路径上彻底绕过反射：用 unsafe.Offsetof 生成闭包
缓存只是“减损”，真正零开销的做法是初始化时算出字段偏移，封装成纯函数闭包。运行时只做指针偏移和类型转换，无反射、无接口、无 GC 分配。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
offset := unsafe.Offsetof(User{}.Name)，再封装为func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 前提：输入必须可寻址（通常传指针），且字段类型和结构体布局稳定（加字段、改顺序需重新生成）
- 实测比缓存反射快 5–10 倍，GC 分配趋近于零；
msgpack、gogoprotobuf等库广泛使用 - 最容易被忽略的一点：别在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存
真正难的不是怎么写闭包，而是判断哪个结构体值得下沉到 unsafe 层；一旦字段布局变动，闭包就失效，且 runtime crash 不报错。
