go 语言明确禁止在结构体字面量中直接使用嵌入类型（embedded type）的提升字段（promoted fields）作为键名初始化，这是语言规范的设计选择，而非编译器缺陷；正确方式是显式构造嵌入类型实例或使用匿名字段名。
在 Go 中，结构体嵌入（embedding）是一种实现代码复用和“组合优于继承”理念的核心机制。当类型 B 嵌入 A（即 type B struct { A }），A 的字段（如 FName、LName）和方法会被提升（promoted）到 B 的命名空间中——这意味着你可以合法地写 b.FName 或调用 b.GetName()。然而，一个常被误解的关键限制是：这些提升字段不能用于 B 的复合字面量（composite literal）中作为字段名。
例如，以下代码会编译失败：
type A struct {
FName, LName string
}
type B struct {
A
}
// ❌ 编译错误：unknown B field 'FName' in struct literal
b := &B{FName: "evan", LName: "mcdonnal"}错误信息清晰指出：FName 和 LName 不被视为 B 的直接字段，因此无法在 B{...} 字面量中作为键使用。
✅ 正确的初始化方式
Go 提供了两种符合规范且语义明确的初始化方式：
方式 1：显式初始化嵌入字段（推荐，清晰直观）
将嵌入类型 A 视为 B 的一个匿名字段，直接传入其结构体字面量：
b := &B{A: A{FName: "evan", LName: "mcdonnal"}}✅ 优势：语义无歧义，明确表达了“用一个 A 实例初始化嵌入字段”，与字段提升机制正交且兼容。
方式 2：利用嵌入字段的匿名性（简洁语法）
由于 A 是匿名字段，Go 允许省略字段名，直接提供 A 类型的值（需注意类型匹配）：
b := &B{A{"evan", "mcdonnal"}} // 位置式初始化（要求 A 无其他字段且顺序固定）
// 或更安全的命名式（推荐）：
b := &B{A: A{FName: "evan", LName: "mcdonnal"}}⚠️ 注意：&B{A{"evan", "mcdonnal"}} 依赖字段顺序，可读性较差；强烈建议始终使用带字段名的显式写法，提升可维护性。
❓ 为什么不允许 B{FName: "...", LName: "..."}？——设计背后的逻辑
这不是编译器缺陷，而是 Go 语言规范（Composite Literals）的有意约束：
"Promoted fields act like ordinary fields of a struct except that they cannot be used as field names in composite literals of the struct."
根本原因在于避免初始化语义歧义。考虑如下复杂场景：
type Inner struct{ X int }
type Outer struct{ Inner }
i := Inner{X: 100}
o1 := Outer{X: 42, Inner: i} // ❓ X=42 是赋给哪个 Inner？先构造零值 Inner 再覆盖？还是忽略？
o2 := Outer{Inner: i, X: 42} // 顺序不同，结果是否应一致？若允许提升字段出现在字面量中，就必须定义复杂的优先级规则（如“显式字段覆盖嵌入字段”或“后出现者胜出”），这将破坏 Go 复合字面量的核心契约：字段初始化顺序无关紧要，且每个字段名至多出现一次。该设计保持了初始化逻辑的确定性、可预测性和静态可分析性。
? 总结与最佳实践
- ✅ 接受并遵循规范：嵌入字段不可用于外层结构体字面量的键名，这是 Go 的稳定行为，非 bug。
- ✅ 始终显式初始化嵌入类型：使用 EmbedType: EmbedType{...} 形式，清晰表达意图，杜绝歧义。
- ✅ 避免位置式嵌入初始化（如 B{A{...}}）：易受字段增删影响，降低健壮性。
- ✅ 结合方法集理解嵌入：字段提升仅影响访问语法（. 操作符），不影响构造语法（{} 字面量）——二者职责分离，恰是 Go 类型系统简洁性的体现。
掌握这一规则，不仅能写出合规、可维护的 Go 代码，更能深入理解 Go “少即是多”（Less is more）的设计哲学：通过明确的限制，换取更大的确定性与工程可控性。
