缓存 reflect.Value 无效，应只缓存 reflect.Type 和字段元数据；FieldByName 性能差，需改用 FieldByIndex；CanSet() 揭示值是否可寻址，非指针值无法 Set；反射应尽量避免，优先用泛型、接口或代码生成。
缓存 reflect.Value 是无效操作
很多人一想到“缓存反射结果”，第一反应就是把 reflect.ValueOf(x) 的返回值存起来复用。这完全行不通——reflect.Value 是非可比较类型，不能当 map 的 key；每次调用都会新建实例，哪怕传入同一个变量，两次得到的 reflect.Value 也不相等。更关键的是，它内部包含指向原始数据的 unsafe.Pointer 和运行时 flag，生命周期绑定在单次调用栈上，缓存后可能引发悬垂指针或 panic。
应该只缓存 reflect.Type 和字段/方法元数据。标准库（如 encoding/json）用的是 uintptr(unsafe.Pointer(t)) 作 key，零开销、稳定、不依赖包路径。
- 别用
t.String()或t.PkgPath() + "." + t.Name()当 key：匿名 struct 无名，多模块版本下 PkgPath 可能冲突 - 缓存结构建议是预计算好的字段信息，比如
struct { Offset uintptr; IsExported bool; Tag string }，而不是裸的[]reflect.StructField - init() 里预热所有类型？没必要。按需加载，首次访问时计算并缓存即可
FieldByName 在循环里等于自找麻烦
reflect.Value.FieldByName("ID") 看起来简洁，但每次调用都在做线性字符串比对。一个 50 字段的结构体，平均要查 25 次才能命中；100 字段就是 50 次。高频循环中，这开销会直接线性放大，远超你想象。
真正该用的是 FieldByIndex：提前把字段名映射到索引，查表是 O(1)。实测显示，10 字段结构体下，FieldByIndex 比 FieldByName 快 8–12 倍；字段越多，差距越明显。
立即学习“go语言免费学习笔记（深入）”；
- 用普通
map[string]int存字段名→索引映射，读多写少场景下比sync.Map更快 - 字段重排（比如中间插入新字段）会让索引失效——这不是 bug，是你没和编译器对齐内存布局
- 如果字段逻辑差异大（跳过某些字段、解析不同 tag），建议缓存到字段级，key 可用
uintptr(unsafe.Pointer(&t)) + field.Name
误以为 CanSet() 只是安全检查
CanSet() 返回 false 不只是“不能设”的提示，它直接暴露了底层是否发生值拷贝。对非指针值调用 reflect.ValueOf(x)，拿到的是副本，CanSet() 必为 false；只有传指针再调 Elem() 才可能为 true。漏掉这步就调 SetString()，运行时 panic 是 reflect: reflect.Value.SetXxx using unaddressable value ——错误信息不带行号，只报包名，排查成本极高。
更隐蔽的问题是：即使 CanSet() == true，修改过程仍可能触发堆分配（比如对 slice 字段调 SetLen）。这时候不如直接用 unsafe 算偏移+指针运算，彻底绕过 Value 封装。
- 热路径上，
unsafe.Offsetof(User{}.Name)+ 类型转换闭包，比任何反射调用都快，GC 分配趋近于零 - 必须确保字段是 exported，且结构体没加
//go:notinheap等特殊标记 - race detector 会报错？加
//go:build !race条件编译，或改用go:linkname
把反射当成万能解药，却不问是否真需要
很多性能问题根本不是反射慢，而是不该用反射。比如 ORM 映射里反复对同一结构体做字段遍历，其实早该用代码生成（go:generate + template）产出专用函数；又比如配置加载器，若 schema 固定，接口抽象 + 手动实现比反射更安全、更快、更易 debug。
反射真正的合理场景，是动态性不可规避的：JSON/YAML 解析、通用 RPC 编解码、依赖注入容器、动态策略路由。一旦进入热点路径、字段数量可控、类型稳定，就要立刻考虑降级方案。
- pprof 里看到
reflect.Value.FieldByName或reflect.Value.Call占 CPU 高位？先确认是不是调用频次本身就不合理 - 频繁 GC？看 heap profile，大概率是
reflect.Value大量逃逸到堆上，不是算法问题，是使用方式错了 - 最常被忽略的一点：反射优化的终点，不是“让反射变快”，而是“让反射消失”。能用泛型、接口、代码生成的地方，就别留它在热路径上
