Go反射中应缓存reflect.Type和reflect.Method，用uintptr(unsafe.Pointer(t))作key；字段访问用预建name→index映射表；避免sync.Map和init预热；极致优化可用unsafe生成零开销闭包。
Go 反射对象本身不能重用——reflect.Value 每次调用 reflect.ValueOf 都新建，不可比较、不可当 map key；真正能且应该重用的，是 reflect.Type 和 reflect.Method 这类只读元数据。
缓存 reflect.Type 要用 uintptr(unsafe.Pointer(t)) 作 key
同一类型的 reflect.Type 在整个程序生命周期中地址唯一且稳定，这是缓存的前提。但别用 t.String() 或 t.PkgPath() + "." + t.Name() 做 key：前者对匿名 struct 返回空字符串，后者在 vendoring 或多模块版本共存时可能冲突。
-
uintptr(unsafe.Pointer(t))是零开销、无字符串拼接、不依赖包路径的标准做法，encoding/json等标准库就这么干 - 缓存结构建议是预计算好的字段信息，比如
type fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，而不是裸的[]reflect.StructField - 别在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存
FieldByName 必须换成字段索引查表
FieldByName 内部是线性遍历所有字段做字符串比对，100 字段的 struct 就要比较 100 次；而 Field(i) 是数组下标访问，常数时间。高频字段访问场景下，这差距可达百倍。
- 提前构建
map[string]int映射（key 是字段名，value 是StructField.Index），后续直接查表 - 这个映射本身也应缓存，key 同样用
uintptr(unsafe.Pointer(t))，避免每次重新遍历 - 别用
sync.Map存它：读多写少场景下，原子操作反而比普通map+sync.RWMutex慢
reflect.Value.Call 的瓶颈不在 Call，而在参数转换和 receiver 校验
reflect.Value.Call 单次开销 100–500ns，真正拖慢吞吐的是每次调用前对 receiver 是否可寻址的校验，以及每个参数逐个做类型转换和封装——哪怕你缓存了 reflect.Method，只要没绕过这一步，性能就上不去。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保传入的是指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v)，否则直接 panic - 缓存目标是
reflect.Method，不是reflect.Value；正确方式是cache[uintptr(unsafe.Pointer(t))][methodName] = method - 错误方式是
map[interface{}]reflect.Method——接口底层含值指针，不同变量即使类型相同也无法命中
热路径彻底绕过反射：用 unsafe 生成零开销闭包
缓存只是“减损”，真正零反射开销的做法，是在初始化时用 unsafe.Offsetof 算出字段偏移，或用 unsafe 解析方法表拿到函数入口地址，再封装为纯函数闭包。
- 例如字段访问：
offset := unsafe.Offsetof(User{}.Name)，再封装为func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 例如方法调用：Go 1.14+ 下
internal/abi.Type布局稳定，可算出方法表偏移和入口地址，构造函数指针调用 - 注意：必须确保输入可寻址、字段/方法签名稳定；否则 runtime crash，且绕过了类型系统校验
最容易被忽略的一点：反射性能问题从来不是“能不能用”，而是“在哪一层暴露”。reflect.Type 和 reflect.Method 缓存错了 key，或者字段索引查表用了 sync.Map，都可能让优化失效甚至更慢。真正关键的，是分清哪些东西可复用、哪些东西必须每次重建、哪些东西干脆不该出现在热路径上。
