Go反射中同名嵌入字段只保留第一个出现的，后续同名字段被忽略；访问被遮蔽字段必须用FieldByIndex指定完整路径，如[1,0]表示进入第二个匿名字段再取其首字段。
嵌入结构体字段名冲突时，reflect.StructField 会返回哪个？
Go 反射不会自动“合并”或“跳过”同名字段，而是按匿名字段嵌入顺序，**只保留第一个出现的同名字段**。后续嵌入结构体中同名字段被完全忽略 —— 这不是 bug，是 Go 类型系统的明确设计。
比如 A 和 B 都有 Name string，struct{ A; B } 反射拿到的 Name 一定来自 A，哪怕 B.Name 在内存布局里物理存在，reflect.Value.FieldByName("Name") 也取不到它。
- 用
reflect.Type.FieldByName("Name")查到的是第一个匹配项，.Index是其在顶层结构体中的嵌入路径（如[0]表示从第 0 个匿名字段进入） - 想访问被遮蔽的
B.Name？必须手动按.Field(1).FieldByName("Name")路径钻取，不能靠名字直取 - 如果两个嵌入结构体字段名相同但类型不同（如
A.Name stringvsB.Name int），代码根本无法编译，反射根本跑不到那一步
reflect.Value.FieldByIndex 是绕过名字冲突的唯一可靠方式
依赖字段名不安全；依赖索引才可控。当你需要精确访问某层嵌入结构体的字段（尤其是被遮蔽的），必须用 FieldByIndex 拼出完整路径。
例如：结构体 S{A, B}，其中 A 和 B 都含 ID，你想取 B.ID：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
val := reflect.ValueOf(s)
bID := val.FieldByIndex([]int{1, 0}) // [1] 进入 B，[0] 取 B 的第一个字段（假设 ID 是 B 的第 0 字段）
- 别硬记索引 —— 先用
reflect.TypeOf(s).Field(1).Type.Field(0)确认B的ID确实是第 0 字段 -
FieldByIndex不做字段名检查，越界直接 panic，务必提前校验len(index) - 嵌入三层以上（如
S{A{B{C}}}），索引数组可能变成[0,0,0]，手写易错，建议封装成fieldByPath(val, "A.B.C.ID")辅助函数
用 reflect.StructTag 区分同名字段的语义，而不是依赖位置
字段名冲突本质是建模问题。与其在反射里硬绕，不如从定义入手：给同名字段加不同 tag，运行时靠 tag 做路由判断。
例如都叫 ID，但一个标记为 json:"user_id"，另一个为 json:"group_id"：
type User struct {
ID int `json:"user_id"`
}
type Group struct {
ID int `json:"group_id"`
}
type Record struct {
User
Group
}
- 反射遍历时用
sf.Tag.Get("json")区分意图，比猜Index更健壮 - 注意：tag 值为空字符串时
Get返回空，不是 nil，别用== ""判定缺失，要用len(sf.Tag.Get("json")) == 0 - tag 不影响内存布局或反射字段顺序，只是元数据，可放心用于决策分支
嵌入指针结构体时，reflect.Value 的 IsNil 容易误判
如果嵌入的是 *T 而非 T，反射拿到的 Field 是 reflect.Ptr 类型，但它的 IsNil() 检查的是该指针是否为 nil —— 而不是其指向的结构体字段是否存在。
- 对
struct{ *A; *B }，即使A为 nil，val.Field(0).FieldByName("Name")仍会 panic：“can't index nil pointer” - 安全做法：先
if !f.IsNil() { v := f.Elem(); ... }，再操作v - 别在未
Elem()前调FieldByName——reflect.Ptr类型没有字段，只有reflect.Struct才有
多重嵌入本身不复杂，难的是字段语义模糊时，反射无法替你做业务判断。名字冲突、nil 指针、tag 缺失 —— 这些地方漏掉一个检查，运行时就崩。写反射代码，得把每个 . 都当成潜在断点来守。
