b.a 和 b.A.a 等价，因 Go 字段提升机制将嵌入类型 A 的导出字段（或同包内可访问的非导出字段）直接提升至 B 的命名空间，二者访问同一内存地址、性能无差异，且仅限直接嵌入、名称唯一时生效。
Go 的选择器（selector）访问嵌入字段时，**不是“自动展开所有层级”，而是严格按字段提升规则解析；只要路径唯一、字段导出且无歧义，b.a 和 b.A.a 完全等价，但前者是编译器自动提升的结果，后者是显式路径——二者底层访问同一内存地址，性能无差别。**
为什么 b.a 能直接访问，而 b.A.a 也合法？
这是 Go 字段提升（field promotion）机制在起作用：当结构体 B 嵌入类型 A（如 A 是导出类型），且 A 中有导出字段（如 A）或同一包内可访问的非导出字段（如 a），编译器会将该字段“提升”到 B 的命名空间中。
前提是：a 在 B 的所有嵌入层级中名称唯一。此时：
-
b.a是提升后的简写，语义清晰、符合 Go 惯用法 -
b.A.a是显式路径，用于调试、文档化，或后续出现重名时作兼容过渡 - 两者生成的机器码一致，无运行时开销差异
ambiguous selector 编译错误怎么触发？
当你嵌入多个含同名字段的结构体，且它们处于同一嵌入深度时，Go 拒绝自动提升，强制你显式指定来源——这是设计上的保守策略，防止隐式行为引入维护风险。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误场景：
- 嵌入
A1和A2，两者都有字段ID：type B struct { A1; A2 } - 访问
b.ID→ 编译报错：ambiguous selector b.ID - 必须写成
b.A1.ID或b.A2.ID - 即使其中一个是未导出类型（如
a1），只要在同一包内定义且字段名冲突，同样触发该错误
嵌入指针字段时，b.a 为什么会 panic？
嵌入 *A 不等于“自动初始化 A”。它只是把 A 的字段投影进来，但底层指针仍是 nil —— 提升只作用于字段名解析，不干预内存生命周期。
-
type B struct { *A; name string }→b.a编译通过，但运行时若b.A == nil，就会 panic - 嵌入非指针类型（
A）则字段被复制，无 nil 风险，但失去共享和节省内存优势 - 调用方法（如
b.Method()）同样要求b.A != nil，因为接收者是*A - 安全做法：初始化时显式赋值，或封装检查逻辑（如
if b.A != nil { ... }）
嵌入未导出类型时，字段还能被提升吗？
能，但仅限于**同一包内**，且仅影响可访问性，不影响提升行为本身。
- 嵌入
type a struct{ X int }（小写类型名）→b.X编译失败：cannot refer to unexported field X - 嵌入
type A struct{ x int }（大写类型，小写字段）→b.x在同一包内合法（因A可导出，x对当前包可见），但外部包无法访问b.x - 关键判断依据是：嵌入类型是否导出（首字母大写），而非字段是否导出；字段可见性由其自身首字母 + 包作用域共同决定
真正容易被忽略的是嵌入深度与字段名唯一性的耦合关系：哪怕只差一层嵌套（比如 B 嵌入 C，C 嵌入 A），A 的字段也不会被提升到 B —— 提升只发生在**直接嵌入**的一层。多层嵌套必须靠显式路径或中间结构体收口。
