Go反射毛刺源于高频未缓存调用；需预热缓存Type与字段索引、避免循环中reflect.ValueOf、操作前必检CanSet并传指针，泛型优先于反射。
Go语言反射本身无法“消除”，只能规避或缓存——毛刺根源不在用不用反射，而在高频、未缓存、未预热的反射调用。
reflect.ValueOf 在循环里反复分配内存
每次 reflect.ValueOf(x) 都会新建一个约 96 字节的 reflect.Value 实例，触发 GC；若在 for 循环中对每条数据都这么干，毛刺直接体现在 p99 延迟上。
- 别写
for _, item := range items { v := reflect.ValueOf(item); v.FieldByName("ID").Int() } - 启动时或首次请求时，用
reflect.TypeOf(T{})获取reflect.Type，再用t.NumField()+t.Field(i)预算出字段名到索引的映射（例如map[string]int{"ID": 0, "Name": 1}） - 后续直接用
v.FieldByIndex([]int{idx})，查表 O(1)，无字符串比对、无遍历开销
CanSet() 被忽略导致 panic 隐藏在运行时
对非指针值调用 reflect.ValueOf(x) 得到的是副本，CanSet() 返回 false；若跳过检查就调 v.SetInt(100)，panic 信息是 reflect: reflect.Value.SetInt using unaddressable value，不带行号，只报包名，排查成本高。
- 必须先判断：
if !v.CanSet() { /* 处理错误或提前返回 */ } - 要修改原值，必须传指针：
v := reflect.ValueOf(&x).Elem()，再检查v.CanSet() - 这个检查不能省，它既是安全阀，也是性能提示：不可设说明你正在操作副本，后续所有 Set 操作都白费
缓存 Type 和字段索引比想象中更关键
reflect.TypeOf(T{}) 每次都新建对象，内部类型元数据虽共享，但外层 reflect.Type 接口实例不复用；NumField() + 字段遍历也重复执行。实测缓存后，单次字段访问快 8–12 倍。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map缓存，key 是reflect.Type（可直接作 map key，无需转字符串），value 是预计算好的字段索引 map 或结构体 - 不要等到请求来了再算；在 init 函数或配置加载完成时预热
- 如果结构体类型固定且不多，甚至可直接定义全局变量缓存，避免 sync.Map 的原子开销
真正难的不是让反射跑起来，而是确认“这里是否真的需要反射”——泛型能覆盖的场景硬套反射，毛刺只是表象，深层是维护成本和类型安全的持续泄漏。
