go 语言明确禁止在结构体字面量中直接使用嵌入类型（embedded type）的提升字段（promoted fields）作为键名初始化，这是语言规范的设计选择，而非编译器缺陷；正确方式是显式构造嵌入类型实例或使用匿名字段名。
在 Go 中，结构体嵌入（embedding）是一种实现组合（composition）的关键机制，它通过匿名字段将被嵌入类型（如 A）的导出字段和方法“提升”（promoted）到嵌入者（如 B）的命名空间中。这使得 b.FName 和 b.GetName() 看似天然属于 B —— 但这种提升仅作用于表达式求值（如字段访问、方法调用），不延伸至结构体字面量（composite literal）的初始化语法。
❌ 错误写法：试图直接初始化提升字段
以下代码会编译失败：
type A struct {
FName string
LName string
}
type B struct {
A // 嵌入 A
}
// 编译错误：unknown B field 'FName' in struct literal
b := &B{FName: "evan", LName: "mcdonnal"} // ❌ 不合法即使 B 实例可正常访问 b.FName，Go 编译器仍拒绝在 B{...} 字面量中将 FName 视为 B 的直接字段名。这不是 bug，而是语言规范的明确约束（见 Go Language Specification: Struct types）：
"Promoted fields act like ordinary fields of a struct except that they cannot be used as field names in composite literals of the struct."
✅ 正确写法：三种合规初始化方式
方式 1：显式构造嵌入类型（推荐，清晰且无歧义）
b := &B{A: A{FName: "evan", LName: "mcdonnal"}}
// 或简写为（利用嵌入字段名即类型名）
b := &B{A: struct{ FName, LName string }{"evan", "mcdonnal"}}方式 2：省略字段名，按声明顺序初始化（需确保嵌入字段为首个且唯一匿名字段）
b := &B{A{"evan", "mcdonnal"}} // ✅ 合法：将 A{} 作为第一个（也是唯一）匿名字段值方式 3：先创建再赋值（适合复杂逻辑或部分初始化）
b := &B{}
b.FName = "evan" // 提升字段可读可写
b.LName = "mcdonnal"⚠️ 为什么不允许直接使用提升字段名？—— 设计背后的严谨性
Go 团队刻意规避该语法，核心在于维护复合字面量的确定性与无歧义性。考虑如下边界场景：
type A struct{ X int }
type B struct{ A; Y int }
a := A{X: 1}
b1 := B{X: 2, A: a} // ❓ 若允许：X=2 是初始化 A 的 X，还是覆盖 a 的 X？
b2 := B{A: a, X: 2} // 顺序不同，语义是否应一致？若开放 X 作为 B 字面量的字段名，则必须定义复杂的优先级规则（如“显式 A: 赋值是否覆盖 X: 赋值？”、“初始化顺序是否影响结果？”），这将破坏 Go 复合字面量“字段顺序无关、语义确定”的设计哲学。当前规范强制开发者显式表明意图（是初始化嵌入实例，还是设置其内部字段），从根本上消除了歧义。
✅ 最佳实践总结
- 永远不要假设提升字段可在字面量中直接使用：这是 Go 的硬性限制，非待修复缺陷；
- 优先使用 嵌入类型名: 值 显式初始化（如 A: A{...}），语义最清晰，兼容性最强；
- 避免依赖字段顺序的省略写法（如 B{A{...}}），尤其当结构体含多个嵌入字段时易出错；
- 方法接收器与字段访问不受此限制——嵌入带来的方法提升和字段访问完全可用，仅初始化语法受限。
理解这一设计，不是接受妥协，而是拥抱 Go 对可预测性、可读性与工具友好性的一贯坚持。
