FieldByName 仅返回首个同名字段值，无法区分多个匿名字段中的同名字段；安全访问需用FieldByIndex或手动构建字段树并递归展开路径。
FieldByName 为什么有时取不到匿名字段的值？
因为 FieldByName 只返回**第一个匹配字段名**，而匿名字段的导出字段会被“提升”到外层结构体作用域——如果两个匿名字段都有 Name，FieldByName("Name") 永远只拿到第一个，且无法区分来源。
- 它不报错，也不提示歧义，静默返回首个匹配项，极易埋下逻辑 bug
- 仅适用于“确定唯一性”的简单场景（如单个匿名字段 + 无重名）
- 真正安全的访问方式是用
FieldByIndex，靠路径定位：比如v.FieldByIndex([]int{0, 1})表示“第 0 个字段（User）的第 1 个子字段（Age）” - 若需按名查找并明确归属，必须先遍历所有字段，结合
field.Anonymous和field.Index构建字段树，再筛选
如何递归展开所有匿名字段并保留完整路径？
匿名字段不是“消失”了，而是被反射扁平化处理了：reflect.TypeOf(t).NumField() 返回的是提升后的总字段数，不是你源码里写的字段个数。要还原嵌套关系，必须手动递归。
- 每次进入
field.Anonymous == true的字段时，就调用同一遍历函数，并把当前索引追加进路径（如从[0]变成[0, 2]） - 非匿名字段直接记录其
field.Name和完整Index路径 - 注意：
field.Type是匿名字段的类型（如reflect.TypeOf(User{})），不是它的值；取值要用v.Field(i)再传入递归 - 常见漏点：忘记对指针解引用（
v.Elem()），或对 nil 指针字段未做空检查，导致 panic
修改匿名字段里的值为什么会 panic？
反射修改字段值的前提是：该字段**可寻址（addressable）且可设置（settable）**。匿名字段本身是结构体类型，但它的字段是否可设，取决于原始变量是否以指针形式传入。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传值（
reflect.ValueOf(emp)）→ 所有字段.CanSet() == false，调用.SetXXX()直接 panic - 必须传指针（
reflect.ValueOf(&emp)），再.Elem()得到可寻址的结构体值 - 即使这样，也要逐层确认：外层结构体可设 → 匿名字段本身可设 → 其子字段可设（例如
User字段是值类型，它内部的Name才是最终可设目标） - 别想当然认为
v.FieldByName("Name").SetString(...)就行得通——先确保v.FieldByName("Name").CanSet() == true
怎么快速判断一个字段是不是匿名字段？
看 reflect.StructField.Anonymous 字段，它就是专为此设计的布尔标识——不是靠字段名为空、不是靠类型名和字段名相同、更不是靠 tag 判断。
-
field.Anonymous == true表示它是匿名字段（如User），此时field.Name是类型名（"User"），不是空字符串 - 基础类型（
int、string）即使没写字段名，Go 语法上根本不允许匿名，编译就报错，所以Anonymous永远为 false - 接口或指向结构体的指针也可以是匿名字段，同样适用
field.Anonymous判断 - 别用
len(field.Name) == 0做判断——这是最常见也最危险的误解
匿名字段在反射中没有魔法，只有两条铁律：靠 Anonymous 标志识别身份，靠 Index 路径定位值。一旦混淆扁平化视图和源码结构，几乎所有操作都会开始“看似正常、实则不可靠”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
