reflect.valueof在循环中性能差因每次分配96字节并触发gc，且fieldbyname需线性字符串比对；应预缓存字段索引、复用reflect.type/value、写前必检canset()。
为什么 reflect.ValueOf 在循环里特别伤性能
每次调用 reflect.ValueOf 都会分配一个新的 reflect.Value 实例（约 96 字节），触发 GC；更关键的是，FieldByName 是线性遍历字段名做字符串比对——10 个字段就要比 10 次，100 个字段就是 100 次。高频循环中，这直接把吞吐量拉垮。
用 FieldByIndex 替代 FieldByName，预缓存字段索引
字段名到索引的映射必须提前算好，不能在循环里反复调用 NumField + Field 遍历。实测缓存后，查找快 8–12 倍。
- 启动时或首次访问时预热：对目标结构体类型调一次
reflect.TypeOf(T{})，再遍历NumField()构建map[string]int - 键直接用字段名字符串，值是
FieldByIndex所需的[]int（单层字段用[]int{i}） - 后续循环中直接
v.FieldByIndex(cache["ID"])，跳过所有字符串比对
别在循环里重复调用 reflect.TypeOf 和 reflect.ValueOf
reflect.TypeOf 每次都新建内部对象，不复用；reflect.ValueOf 不仅分配内存，还隐含指针解包和 flag 初始化。这两者都该提出来，只做一次。
- 把
reflect.Type和reflect.Value的“模板”缓存在包级变量或结构体字段里 - 循环内只调
v := templateValue.Clone().SetPointer(unsafe.Pointer(&item))（需配合unsafe）或更稳妥地：用reflect.New(t).Elem()初始化后Set() - 若只是读取，可直接用
templateValue.FieldByIndex(...)，再调Set()赋新值
CanSet() 不只是安全检查，漏判会导致 panic 难定位
对非指针值调用 reflect.ValueOf(x) 得到的是副本，CanSet() 返回 false；只有传入指针并 Elem() 才能真正修改原值。但更危险的是：漏掉 CanSet() 就直接 SetInt()，运行时报 reflect: reflect.Value.SetInt using unaddressable value——错误不带行号，只提示包名，排查成本极高。
- 所有写操作前必须加
if !v.CanSet() { ... }判断 - 如果目标是结构体字段，确保原始值是以指针形式传入，且字段本身未被导出（首字母小写）也会导致
CanSet()为false - 宁可多判一次，也不要靠文档赌“它应该可设”
真正难的不是让反射跑起来，而是判断“这里到底该不该用反射”——很多本可用泛型或接口抽象解决的地方，硬套反射只会把性能问题和 panic 隐患埋得更深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
