reflect.TypeOf 和 reflect.ValueOf 调用慢是因为运行时动态解析类型、分配临时结构体，高频使用导致 GC 压力和 CPU 开销上升；应缓存 reflect.Type 和 reflect.Method，避免缓存 reflect.Value 或 interface{} 作 key。
为什么 reflect.TypeOf 和 reflect.ValueOf 一调用就慢？
因为每次调用都在运行时动态解析类型信息，绕过编译期优化，还要分配临时 reflect.Type 和 reflect.Value 结构体。尤其在高频路径（如 JSON 序列化、RPC 参数解包）里反复调用，GC 压力和 CPU 开销会明显上涨。
这不是“能用就行”的问题——实测在循环中每秒调用 10 万次 reflect.TypeOf，比缓存后慢 3–5 倍，且内存分配量翻倍。
- 类型对象本身是全局唯一的，
reflect.TypeOf(x)对同一类型返回的指针地址恒定 -
reflect.ValueOf每次都新建实例，但底层类型元数据不重复计算 - 缓存重点应放在
reflect.Type和常用reflect.Method查找结果上，而非reflect.Value
用 sync.Map 缓存 reflect.Type 安全吗？
安全，但没必要。Go 的 reflect.Type 是只读、并发安全的，且同一类型的 reflect.TypeOf 返回值指针相等。更轻量的做法是直接用 map[uintptr]reflect.Type 加 sync.Once 初始化，或干脆用 unsafe.Pointer 做 key（需配合 reflect.TypeOf 一次取址）。
常见错误是把 interface{} 当 key：不同变量即使类型相同，map[interface{}]T 无法命中缓存，因为接口底层包含值指针和类型指针两部分。
立即学习“go语言免费学习笔记（深入）”；
- 正确 key：用
uintptr(unsafe.Pointer(reflect.TypeOf(x).UnsafePointer()))或直接存reflect.Type指针（*reflect.rtype） - 错误 key：
map[interface{}]T、map[string]T（靠Type.String()，字符串分配+哈希开销大） -
sync.Map在读多写少场景有额外原子操作开销，纯类型缓存建议用普通 map +sync.Once初始化全局表
字段访问和方法调用怎么缓存才真正省事？
别缓存 reflect.Value.Field(i) 这种结果——它依赖具体实例，没法复用。要缓存的是“访问路径”：比如结构体第 2 个字段的偏移量、某个方法的 reflect.Method 实例、或者封装好的 getter 函数闭包。
典型做法是预生成一个函数：输入 interface{}，输出字段值（interface{} 或具体类型），这样后续调用完全避开反射。
- 用
t.Field(i).Offset+unsafe.Offsetof算出偏移，再用unsafe.Pointer直接取值，零反射开销 - 缓存
t.MethodByName("Foo")返回的reflect.Method，而不是每次重查 - 避免缓存
reflect.Value.Method(i).Call()的结果；应缓存reflect.Value.Method(i)本身，再在热路径调用.Call() - 注意导出性：非导出字段/方法无法通过反射调用，缓存前必须检查
CanInterface()或CanAddr()
第三方库如 goccy/go-json 或 msgpack 为啥快？
它们根本没在运行时用反射——而是在构建阶段（go:generate）或首次调用时，用反射分析一次类型，然后生成并编译专用的序列化函数（类似模板代码），后续全走原生结构体访问。你手动缓存的终点，就是它们默认做的事。
所以真要极致性能，别死磕反射缓存；优先考虑：是否能用 codegen（如 easyjson）、是否可改用 unsafe + 偏移硬编码、或者接受一点初始化延迟换长期零开销。
最容易被忽略的一点：缓存本身有生命周期管理成本。如果类型集动态变化（比如插件系统加载新 struct），缓存可能泄漏或失效，这时候反而不如每次反射来得干净。
