go反射开箱即用但默认性能差，主因是调用方式、频率及缓存缺失；reflect.valueof在循环中频繁分配内存且fieldbyname线性比对字段名，应预缓存type和字段索引并用fieldbyindex替代。
Go反射不是“配置出来”的，它开箱即用，但默认就是慢的；性能问题不来自配置错误，而来自调用方式、频率和缓存缺失。
为什么 reflect.ValueOf 在循环里特别伤性能
每次调用 reflect.ValueOf 都会分配新的 reflect.Value 实例（约96字节），触发 GC；更关键的是，FieldByName 是线性遍历字段名做字符串比对，10个字段就要比10次，100个字段就是100次——这在高频循环中直接拖垮吞吐量。
- 避免写
for _, item := range items { v := reflect.ValueOf(item); v.FieldByName("ID").Int() } - 把
reflect.TypeOf和字段索引预计算好，缓存到 map 或结构体里 - 用
FieldByIndex替代FieldByName，索引查表是 O(1)
CanSet 不只是安全检查，它决定你能不能绕过复制开销
对非指针值调用 reflect.ValueOf(x) 得到的是副本，CanSet() 返回 false；只有传入指针并调用 Elem() 才能真正修改原值。但更重要的是：如果漏掉 CanSet() 就直接 SetXxx，运行时 panic 信息是 reflect: reflect.Value.SetXxx using unaddressable value ——这个错误不提示哪一行，只提示哪个包，排查成本高。
- 永远先判断
v.CanSet()再操作，尤其处理 interface{} 输入时 - 用
v.Addr().CanSet()检查是否可取地址，比直接v.Elem().CanSet()更早暴露问题 - 如果原始值不可寻址（比如字面量、map value），
Addr()会 panic，要兜底捕获
缓存 reflect.Type 和字段映射比你想的更必要
同一个结构体类型，反复调用 reflect.TypeOf(T{}) 不会复用内部结构，每次都是新对象；而 NumField() + Field(i) 遍历也重复执行。实测显示，缓存字段名到索引的 map 查找比每次 FieldByName 快 8–12 倍。
- 用
sync.Map存reflect.Type → map[string]int，键是字段名，值是FieldByIndex所需索引 - 启动时或首次访问时预热缓存，别等到请求来了再算
- 注意：
reflect.Type可以直接当 map key，不需要转字符串
真正难的不是学会怎么用 reflect，而是判断“这里到底该不该用”——很多本可用类型断言或泛型解决的地方，硬套反射只会把问题埋得更深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
