应预缓存 reflect.value 和 reflect.type 并复用字段索引，避免循环中反复调用 reflect.valueof 和 fieldbyname 导致堆分配与 o(n) 查找开销。
reflect.ValueOf 在循环里反复调用会触发大量堆分配
每次 reflect.ValueOf 都会构造一个新的 reflect.Value 实例（内部含 unsafe.Pointer + flag + type 指针），编译器几乎无法将其优化到栈上，结果就是每个调用都逃逸到堆，带来 GC 压力和内存抖动。尤其在 JSON 解码、ORM 映射等高频场景中，成千上万个对象挨个 ValueOf，性能直接掉一个数量级。
- 实测：对结构体切片做字段赋值，
reflect.ValueOf(item)在循环内调用比预缓存reflect.Value慢 20–30 倍 - 别写
for _, x := range xs { v := reflect.ValueOf(x); v.Field(0).SetString(...) } - 正确做法是：提前用
reflect.New(t).Elem()构造模板值，再通过Set()复制原始数据（注意传指针）
FieldByName 是 O(n) 字符串比对，必须换成 FieldByIndex
FieldByName 内部是线性遍历所有字段名并做 == 比较，100 字段就要比 100 次。它不缓存索引，也不支持大小写忽略，纯靠 runtime 查表。哪怕只调用一次，开销也比直接索引高 5–8 倍；在热路径里反复调用，就是稳稳的性能黑洞。
- 字段名到索引的映射应预热：启动时或首次访问时调用
t.FieldByName("ID")一次，记下StructField.Index - 缓存结构建议用
map[string]int或sync.Map，键可直接用string（字段名已 intern） - 后续一律用
v.FieldByIndex([]int{idx})或v.Field(idx)，跳过字符串查找
reflect.TypeOf 不复用内部结构，缓存 Type 和 Value 模板更关键
reflect.TypeOf(T{}) 每次都新建 reflect.rtype 对象，虽然底层类型元数据共享，但接口包装层仍要分配。更重要的是，NumField()、Field(i) 这些方法每次调用都重新解析字段布局——这不是 CPU 时间问题，而是无谓的重复工作。
- 把
reflect.Type和常用字段索引打包进一个结构体，比如：type structCache struct { t reflect.Type idIdx, nameIdx int } - 全局单例或按类型注册，避免每次请求都重算
- 如果需修改原值，缓存的必须是
reflect.Value模板（由reflect.New(t).Elem()得到），而非reflect.ValueOf(&x)的副本
CanSet() 不只是安全检查，漏判会导致 panic 且难定位
对非地址值调用 reflect.ValueOf(x) 得到的是只读副本，CanSet() 返回 false；此时若强行 SetString()，运行时报 reflect: reflect.Value.SetXxx using unaddressable value。这个错误不带行号，只提示包名，排查成本极高。
- 务必在 Set 前加
if !v.CanSet() { ... }判断 - 真正可修改的只有：指针类型的
Elem()、接口值的底层可寻址值、或通过reflect.New(t).Elem()创建的模板 - 泛型替代方案（如
func[T any] SetField(t *T, f string, v any)）能完全规避此问题，但反射路径下必须守住这道关
ValueOf 仍分配，GC 照样报警。这些点串起来，才是反射优化落地的完整链路。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
