Go反射性能瓶颈在于重复的reflect.ValueOf、FieldByName等运行时操作，而非指针本身；应预缓存reflect.Type和字段索引，用FieldByIndex替代FieldByName，并确保传入指针。
Go 反射里指针操作本身不慢，慢的是你每次都在重复做类型解析、字段查找、参数校验这些事；真正要减的不是指针开销，而是围绕指针反复调用 reflect.ValueOf、FieldByName、Call 带来的运行时负担。
为什么 reflect.ValueOf(&v) 在循环里特别伤性能
每次调用 reflect.ValueOf(&v) 都会新建一个 reflect.Value 实例（约 96 字节），触发 GC；更关键的是，它底层仍要查类型表、封装接口、设置标志位。高频场景下（比如 HTTP handler 解包请求体），这不是“多一点点开销”，而是直接把吞吐压下去。
- 别写
for _, item := range items { v := reflect.ValueOf(&item); v.FieldByName("ID").Int() } - 把
reflect.TypeOf(&T{})和字段索引预计算好，缓存到结构体或 map 中 -
reflect.ValueOf的结果不能当 map key，缓存它等于白干；只缓存reflect.Type或字段偏移数组[]int - 确保传入的是指针——
reflect.ValueOf(v)（值类型）得到的是副本，CanSet()返回 false，后续SetXxx会 panic，错误信息还不带行号
用 FieldByIndex 替代 FieldByName 绕过字符串比对
FieldByName 是线性搜索：100 字段的 struct，平均要比 50 次字符串才能命中；而 FieldByIndex 是纯数组下标访问，常数时间。这在热路径上是数量级差异。
- 启动时或首次访问时，用
t := reflect.TypeOf(&T{}).Elem(); for i := 0; i 预算索引 - 缓存结构推荐：
type fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，比裸的[]reflect.StructField更轻量 - key 构造用
uintptr(unsafe.Pointer(t))，不是t.String()（匿名 struct 失效）也不是map[interface{}]T（接口底层含值指针，无法命中） - 别用
sync.Map存字段索引映射——读多写少，原子操作反而比普通map+sync.RWMutex慢
热路径彻底绕过反射：用 unsafe.Offsetof 生成闭包
缓存只是“减损”，真正零反射开销的做法，是在初始化时算出字段偏移，然后封装成纯函数闭包。运行时只做指针偏移和类型转换，无接口、无分配、无 GC。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
offset := unsafe.Offsetof(User{}.Name); getter := func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 前提：输入必须是可寻址的（通常传
*User），且字段类型和内存布局稳定（加字段、改顺序需重新生成） - 实测比缓存反射快 5–10 倍，GC 分配趋近于零；
msgpack、gogoprotobuf等高性能库都这么干 - 别在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存；缓存应懒构造、按需加载
方法调用别碰 reflect.Value.Call，缓存 reflect.Method 也没用
reflect.Value.Call 慢不在“调用”动作本身，而在每次调用前的 receiver 可寻址性校验 + 参数类型逐个转换。哪怕你缓存了 reflect.Method，只要还走 .Call()，就逃不开这两步开销。
- 必须确保 receiver 是指针：
reflect.ValueOf(&v).MethodByName("Foo")，不是reflect.ValueOf(v) - 检查
method.IsValid()，否则 panic 信息是call of reflect.Value.Call on zero Value，排查成本高 - 参数数组每个元素必须严格匹配签名——
int和int64视为不同类型，不调.Convert()就 panic - 真正有效的缓存是：
cache[uintptr(unsafe.Pointer(t))][methodName] = method，其中t是reflect.TypeOf(&v).Elem()得到的结构体类型 - Go 1.14+ 可用
internal/abi直接算方法入口地址，再用unsafe构造函数指针调用——但绕过类型系统校验，错一点就是 runtime crash
最容易被忽略的一点：很多地方根本不需要反射。类型断言、泛型、代码生成（go:generate）能解决 90% 的“通用序列化/绑定”需求，而且性能是数量级提升。反射该用在 deep copy 任意 struct、调试 dump interface{}、插件加载未知类型这些刚性场景，而不是日常字段访问或方法调用。
