Go反射性能差是因类型查找、临时分配和线性搜索等开销；应缓存reflect.Type（用uintptr(unsafe.Pointer(t))作key）、预建字段索引映射、避免sync.Map，并在热路径用unsafe生成零开销闭包。
Go 反射慢不是错觉，是实打实的运行时开销：每次 reflect.TypeOf 或 reflect.ValueOf 都要查类型表、分配临时结构体、触发接口转换；FieldByName 是线性搜索；Method.Call 要做方法名哈希+参数校验+栈帧构建。高频场景下（比如 JSON 序列化、ORM 字段映射），它真能拖垮吞吐量。
缓存 reflect.Type 和字段元数据，别缓存 reflect.Value
同一类型的 reflect.Type 在整个程序生命周期内地址唯一且稳定，可安全用作缓存 key；而 reflect.Value 每次调用都新建，不可比较、不能当 map key，缓存它等于白干。
- 推荐 key 方式：
uintptr(unsafe.Pointer(t))—— 零开销、无字符串拼接、不依赖包路径，标准库（如encoding/json）就这么干 - 避免用
t.String()或t.PkgPath() + "." + t.Name()做 key：前者对匿名 struct 无效，后者在 vendoring 或模块多版本共存时可能冲突 - 缓存内容建议是预计算好的结构体，比如：
type fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，而不是裸的[]reflect.StructField - 不要在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存
用字段索引代替 FieldByName，避开 O(n) 查找
FieldByName 内部是遍历所有字段做字符串比对，100 字段的 struct 就要比 100 次；而 Field(i) 是数组下标访问，常数时间。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在初始化阶段（比如第一次处理某类型时）建好字段名 → 索引映射：
map[string]int，后续直接查表 - 别用
sync.Map存这个映射：读多写少场景下，它的原子操作反而比普通map+sync.RWMutex慢 - 如果字段逻辑差异大（比如某些字段要跳过、某些需解析 tag），缓存到字段级更灵活，但 key 构造稍复杂，可用
uintptr(unsafe.Pointer(&t)) + field.Name拼接
热路径彻底绕过反射：生成 getter/setter 闭包
缓存只是“减损”，真正零反射开销的做法，是在初始化时用 unsafe 算出字段偏移，然后生成一个纯函数闭包，运行时只做指针偏移和类型转换。
立即学习“go语言免费学习笔记（深入）”；
- 例如：对
User.Name字段，预计算offset := unsafe.Offsetof(User{}.Name)，再封装为func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 这种方法在序列化库（如
msgpack、gogoprotobuf）中广泛使用，实测比缓存反射快 5–10 倍，GC 分配趋近于零 - 注意：必须确保输入是可寻址的（通常传指针），且字段类型稳定；若结构体布局可能变化（如加字段、改顺序），需重新生成
最容易被忽略的一点是：缓存本身也有成本。比如用 sync.Map 存 reflect.Type → 字段列表，看似线程安全，但每次读都要原子 load，实际比普通 map + RWMutex 慢；而用 uintptr 做 key 虽快，但得确保类型没被 GC（命名类型不会，但接口类型需小心）。优化反射不是堆技巧，而是明确「哪一层值得缓」——字段访问？方法调用？还是整个序列化流程？选错层级，投入产出比会很差。
