Go反射中匿名字段提升是编译器在定义阶段完成的语义行为，反射仅观察；只有匿名且导出的嵌套结构体字段才会被提升，FieldByName不递归查找提升字段，需用FieldByIndex配合Index路径或手动展开，访问前须判nil。
Go反射中匿名字段的字段提升（field promotion）怎么触发
Go反射本身不“触发”字段提升，那是编译器在类型定义阶段完成的语义行为。反射看到的 reflect.StructField 里，Anonymous 字段为 true 的成员，才是被提升的匿名字段。但关键点在于：只有当嵌套结构体是匿名（无字段名）且导出（首字母大写）时，其字段才会被提升到外层结构体的字段列表中。
- 如果嵌套结构体带了字段名（比如
Info User），那它就是普通字段，不会提升 - 如果匿名结构体本身非导出（如
user struct{...}），即使匿名，其字段也不会出现在外层可反射访问的字段集中 -
reflect.Type.NumField()返回的是“逻辑字段数”，已包含提升后的字段；而reflect.Type.Field(i)返回的StructField中，Index字段记录的是该字段在原始内存布局中的嵌套路径（比如[1 0]表示第1个字段的第0个字段）
用反射访问匿名嵌套字段时，FieldByName 为什么找不到
因为 FieldByName 只查当前层级的字段名，不递归搜索提升后的字段。它只认“直接定义在本结构体里的名字”，不认被提升上来的名字——哪怕那个名字在结构体字面量里看起来像是顶层字段。
- 要访问提升后的字段，必须手动展开嵌套路径：先用
FieldByName拿到匿名字段的reflect.Value，再在其上继续调用FieldByName - 或者遍历所有字段（
NumField+Field），检查每个StructField.Anonymous是否为true，再递归进它的类型里找目标字段名 - 常见错误现象：
panic: reflect: call of reflect.Value.FieldByName on zero Value，往往是因为前一步拿到的匿名字段值是空（比如 nil 指针或未初始化结构体）
reflect.Value.FieldByIndex 的 index 怎么算才对
FieldByIndex 接收的是一个整数切片，表示从外到内的嵌套路径索引。它不依赖字段名，只依赖结构体定义顺序和内存布局，所以更稳定，也更适合处理匿名嵌套。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 索引序列不是“扁平序号”，而是路径：比如
type A struct{ B struct{ C int } }，要取C，得用FieldByIndex([]int{0, 0})（第0个字段B，它的第0个字段C） - 对于匿名字段，路径同样适用：如果
A是struct{ B struct{ C int } }，那C还是[0 0]；但如果A是struct{ struct{ C int } }，那C就是[0]（因为匿名字段本身是第0个字段，C是它内部第0个字段） - 容易踩的坑：硬编码
[]int路径，一旦结构体字段顺序调整就失效；更安全的做法是用reflect.TypeOf(t).FieldByName("C").Index获取路径，它返回的就是可用于FieldByIndex的切片
反射访问嵌套字段时，nil 指针和零值导致 panic 的典型场景
匿名字段如果是指针类型（比如 *User），且值为 nil，任何对其调用 FieldByName 或 FieldByIndex 都会 panic，因为 reflect.Value 无法解引用空指针。
立即学习“go语言免费学习笔记（深入）”；
- 必须在访问前检查：
v := val.Field(i); if v.Kind() == reflect.Ptr && v.IsNil() { ... } - 同样，如果匿名字段是接口类型且为
nil，v.Elem()也会 panic - 使用场景常见于 ORM 映射、API 请求体解析：前端没传某个嵌套对象，后端结构体对应字段为
nil，反射代码没判空就直奔子字段，立刻崩 - 一个轻量判断方式：
if !v.IsValid() || (v.Kind() == reflect.Ptr && v.IsNil())，这两项覆盖了绝大多数空值陷阱
字段提升是编译期行为，反射只是观察者；真正麻烦的从来不是“能不能访问”，而是“在哪个时刻、以什么方式、是否还有效”。路径索引、nil 判定、匿名标识，三者缺一不可。
