fieldbyname不处理嵌入字段，仅搜索当前结构体直接字段；需递归遍历匿名字段并正确调用elem()才能访问嵌入字段值，否则易panic或返回零值。
FieldByName 在匿名字段上查不到就卡住
FieldByName 本身不处理嵌入逻辑，它只在当前结构体的直接字段中线性搜索。哪怕你嵌了 Person，里面有个导出字段 Name，v.FieldByName("Name") 也大概率返回零值——不是因为没找到，而是因为这个 Name 不在顶层字段列表里，它属于嵌入字段的子字段。
常见现象是：代码没 panic，但取出来是空字符串或 0，后续调用 .SetString() 直接崩溃，错误信息为 reflect: call of reflect.Value.SetString on zero Value。
- 必须先确认目标字段是否被提升：调用
v.Type().Field(i).Anonymous == true判断是否为匿名字段 - 若为
true，得用v.Field(i)取出值，再递归进它的Type().NumField() - 嵌入的是指针（如
*Person）时，要先.Elem()，否则NumField()panic
遍历所有字段构建索引比每次 FieldByName 快 100 倍以上
匿名字段导致字段总数膨胀，但真正影响性能的是查找方式。一个含 3 层嵌套、共 42 个导出字段的结构体，FieldByName("CreatedAt") 平均要比较 28 次才能命中；而预建 map[string]int 映射后，v.Field(idxMap["CreatedAt"]) 是纯数组下标访问。
- 缓存 key 推荐用
uintptr(unsafe.Pointer(t))，不是t.String()或拼接包路径 - 字段索引映射建议在首次访问时惰性生成，避免
init()预热浪费内存 - 别用
sync.Map存这个映射：读多写少场景下，普通map+sync.RWMutex更快
反射修改匿名字段值前漏掉 .Elem() 就 panic
修改字段的前提是可寻址且可设置。reflect.ValueOf(u) 得到的是副本，.CanSet() 永远为 false；必须传指针：reflect.ValueOf(&u).Elem() 才拿到可寻址的根值。但到这里还没完——嵌入字段本身可能又是值类型（如 Person），它内部的 Name 字段仍不可设，除非你确保整个链路都可寻址。
- 逐层检查：
v.CanAddr() && v.CanSet()→ 对每个嵌入字段重复该判断 - 如果嵌入的是
*Person，需v.Field(i).Elem().FieldByName("Name")，中间缺一次.Elem()就 panic - 小写字母开头的字段（如
name）即使可寻址也无法设置，这是语言规则，反射绕不过
真正零开销的方案是生成 unsafe 闭包，不是缓存反射
缓存 reflect.Type 和字段索引只是“减损”，仍有接口转换和函数调用开销。高频路径（如序列化循环）应直接跳过反射：在初始化时用 unsafe.Offsetof(User{}.Name) 算出偏移量，封装成闭包，运行时只做指针运算和类型转换。
例如：
offset := unsafe.Offsetof(User{}.Name)
getter := func(v interface{}) string {
return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset))
}
这种写法实测比缓存反射快 5–10 倍，GC 分配趋近于零。但要注意：结构体字段顺序一旦变化（比如加字段、改声明顺序），偏移量就失效，必须重新生成。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
