FieldByName 静默返回首个同名字段，无法访问被遮蔽的匿名字段；需用 FieldByIndex 按路径定位，且必须确保每层可寻址和可设置。
FieldByName 会静默返回第一个同名字段，无法访问被遮蔽的匿名字段——这不是 bug，是 Go 反射的设计事实。
FieldByName 为什么取不到你想要的匿名字段值
当你有 struct{ A; B }，而 A 和 B 都含 Name 字段时，v.FieldByName("Name") 永远只返回 A.Name 对应的 reflect.Value。它不报错、不提示歧义，也不提供“第二个匹配项”的接口。
- 根本原因是：Go 反射在构建字段索引时，按声明顺序扁平化所有导出字段，同名字段仅保留首个（
A.Name），后续的（B.Name）被跳过 - 编译器层面也禁止直接写
s.Name，会报ambiguous selector；反射却“悄悄选一个”，更易埋逻辑隐患 - 若你依赖字段名做映射（如 JSON key → struct field），这种静默行为会导致数据错位，且极难调试
安全访问被遮蔽字段：必须用 FieldByIndex 拼路径
想明确拿到 B.Name，唯一可靠方式是绕过名字，用索引定位：v.FieldByIndex([]int{1, 0}) 表示“进入第 1 个匿名字段（B），再取它的第 0 个字段（假设 Name 是 B 的首字段）”。
- 索引数组长度必须 ≤ 嵌套深度，越界直接
panic: reflect: FieldByIndex out of bounds - 别硬记
[1,0]—— 先查类型：reflect.TypeOf(s).Field(1).Type.Field(0).Name确认目标字段确实是Name - 嵌入三层以上（如
S{A{B{C}}}）时，路径变成[0,0,0]，建议封装辅助函数fieldByPath(v, "A.B.C.Name")，内部解析字符串并逐层FieldByIndex
递归展开所有匿名字段并保留完整路径
Go 反射不会自动还原嵌套结构，NumField() 返回的是扁平后的字段总数，不是源码中写的字段数。要重建字段树，必须手动递归遍历。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 核心判断依据是
reflect.StructField.Anonymous == true，不是字段名为空、不是类型名匹配、也不是 tag 内容 - 对每个字段：
if f.Anonymous { WalkFields(v.Field(i), append(path, i)) }，非匿名字段则记录f.Name和完整path - 注意指针嵌入：
*Person的Anonymous仍为true，但调用v.Field(i).NumField()前必须先.Elem()，否则 panic - 常见漏点：传入的是
reflect.ValueOf(u)（不可寻址副本），导致递归中.Field(i)后无法继续取子字段值；应统一用reflect.ValueOf(&u).Elem()
修改匿名字段里的值为什么会 panic
反射赋值失败最常见的原因是“不可寻址”，尤其在嵌套匿名字段场景下，需逐层确认可设置性。
- 起点必须是可寻址的：
reflect.ValueOf(&s).Elem()，而非reflect.ValueOf(s) - 每层都要检查：
v.FieldByIndex(path).CanSet() == true—— 即使外层可设，A字段本身是值类型（非指针），其内部字段也可能因原始结构体未以指针传入而不可设 - 未导出字段（小写开头）永远
CanSet() == false，反射也无法绕过 Go 的导出规则 - 典型 panic 信息：
reflect: reflect.Value.SetString using unaddressable value，本质就是漏了某一层的.Addr().Elem()链
最易被忽略的是：字段名冲突在编译期就被拒绝，但反射却用静默选择掩盖问题；一旦业务逻辑依赖“第二个同名字段”，上线后可能只在特定数据分支才暴露，排查成本极高。
