传值导致结构体完整拷贝、canset()恒为false且gc压力大；传指针仅拷贝8字节、需.elem()才能修改，性能高3–5倍。fieldbyname线性遍历慢于field(i)，须缓存type和字段索引。
reflect.ValueOf 传值 vs 传指针的性能和行为差异
传值进去（reflect.ValueOf(s)）得到的是结构体副本，CanSet() 永远返回 false；传指针（reflect.ValueOf(&s)）再调用 .Elem() 才能获得可修改的 reflect.Value。但更关键的是性能：传值会触发一次结构体完整拷贝（尤其是含 slice、map 或嵌套 struct 时），而传指针只拷贝一个指针（8 字节）。实测中，1KB 结构体传值比传指针慢 3–5 倍，且 GC 压力明显上升。
- 漏掉
.Elem()会导致操作指针本身而非目标 struct，.FieldByName("X")可能 panic 或静默失败 -
reflect.ValueOf(nil)返回无效值，后续调用.Kind()或.Type()会 panic，必须先.IsValid() - 若仅需读取字段，
reflect.ValueOf(&s).Elem()和reflect.ValueOf(s)在反射层开销接近；但前者支持写，后者完全不支持
new(T)、T{}、&T{} 在反射上下文中的实际表现
这三种初始化方式在反射使用中影响的是底层内存布局和逃逸行为，进而间接决定 reflect.ValueOf 的分配成本：
-
new(T)总是在堆上分配零值*T，reflect.ValueOf(new(T))得到的是指针的反射值，需.Elem()才能访问字段；它不支持字段初始化，灵活性差 -
T{}创建栈上值（小结构体）或逃逸到堆（大结构体或被闭包捕获），reflect.ValueOf(T{})触发一次完整值拷贝，对大结构体尤其昂贵 -
&T{}是最常用模式：显式构造并取地址，reflect.ValueOf(&T{})只拷贝指针，后续.Elem()访问字段无额外复制开销；编译器也更容易优化
注意：reflect.ValueOf 对 &T{} 和 new(T) 的处理路径几乎一致，但前者语义清晰、可控，后者容易和 new 的历史用法混淆。
FieldByName 为什么比 Field(i) 慢一个数量级
FieldByName 不是哈希查找，而是从 0 开始线性遍历所有导出字段，逐个比对字符串。字段数越多，平均比较次数越接近 n/2；每次比对还涉及临时 reflect.StructField 构造和内存分配。
- 10 字段结构体，
FieldByName("ID")平均比 5 次；100 字段则平均比 50 次——这还没算字符串哈希和内存分配开销 -
Field(0)是纯索引查表，O(1)，无字符串操作，无额外分配 - 拼错字段名（如传
"id"但结构体是"ID"）时，FieldByName静默返回零值reflect.Value，极易埋下难以定位的 bug - 非导出字段（小写首字母）永远无法被
FieldByName访问，即使你传了指针进去
缓存 Type 和字段索引是刚需，不是可选项
同一个结构体类型，反复调用 reflect.TypeOf(T{}) 不会复用内部元数据，每次都是新对象；NumField() + Field(i) 也是重复遍历。实测显示，缓存 reflect.Type → 字段名 → 索引的映射，比每次都 FieldByName 快 8–12 倍。
- 用
sync.Map存reflect.Type为 key（不用转字符串，reflect.Type本身可作 map key） - 缓存内容应是
map[string]int，值为FieldByIndex所需的整数索引数组（如[]int{0}表示第一个字段） - 首次访问时预热，别等到请求进来才计算；避免在 handler 中做
reflect.TypeOf(v).FieldByName - 不要缓存
reflect.Value，它绑定具体实例，不能跨对象复用；只缓存reflect.Type和索引
真正难的从来不是怎么写对反射代码，而是判断“这个字段读取逻辑是否真的需要运行时动态性”——很多场景下，提前生成字段索引或改用泛型，比硬上反射更稳更快。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
