go 语言明确禁止在结构体字面量中直接使用嵌入类型（embedded type）的提升字段（promoted fields）作为键名初始化，这是语言规范的设计选择，而非编译器缺陷；其核心目的在于避免初始化歧义、保障复合字面量语义的确定性与一致性。
在 Go 中，当一个结构体嵌入另一个类型（如 type B struct { A }），被嵌入类型 A 的字段（如 FName、LName）会“提升”（promoted）为 B 的可访问字段——这意味着 b.FName 合法，b.GetName() 也能正常调用（若方法被提升）。但提升仅作用于表达式求值（selector）层面，不延伸至结构体字面量（composite literal）的初始化语法中。
根据 Go 语言规范 明确规定：
Promoted fields act like ordinary fields of a struct except that they cannot be used as field names in composite literals of the struct.
这意味着以下写法是非法的：
b := &B{FName: "evan", LName: "mcdonnal"} // ❌ 编译错误：unknown B field 'FName'而合法的等价写法必须显式构造嵌入字段：
b := &B{A: A{FName: "evan", LName: "mcdonnal"}} // ✅ 推荐：清晰、无歧义
// 或简写为（利用匿名字段名即类型名）
b := &B{A: {FName: "evan", LName: "mcdonnal"}} // ✅ 等效且更简洁为什么不允许？关键在于语义确定性
允许 &B{FName: "x"} 会引发两类根本性歧义：
多级嵌入冲突：若 B 嵌入 A，而 A 又嵌入 C，且 C 也有字段 FName，则 FName 应归属哪一层？提升规则在 selector 中有明确定义（最内层优先），但在字面量中无法自然映射该逻辑。
-
混合初始化的顺序与覆盖问题（规范原文所警示）：
type A struct{ X int } type B struct{ A } a := A{X: 1} b := B{X: 2, A: a} // ❌ 若允许，语义是什么？- 是先用 X: 2 初始化一个临时 A，再用 A: a 覆盖整个嵌入字段？
- 还是 X: 2 和 A: a 并行初始化，导致 X 被覆盖两次？
- 若交换顺序为 B{A: a, X: 2}，结果是否相同？
Go 复合字面量的核心契约是：字段初始化顺序无关紧要，且每个字段至多被赋值一次。引入提升字段作为字面量键名将破坏这一契约，迫使编译器引入复杂、易错的“隐式字段路由”规则，违背 Go “少即是多”（Less is more）的设计哲学。
正确实践建议
- ✅ 始终显式初始化嵌入字段：B{A: {FName: "...", LName: "..."}}
- ✅ 利用零值与后续赋值（适合动态场景）：
b := &B{} b.FName = "evan" b.LName = "mcdonnal" - ⚠️ 避免过度嵌入：若需频繁按提升字段初始化，应审视设计——是否 B 实际上应组合 A 而非嵌入？嵌入应服务于“is-a”语义（如 Dog is an Animal），而非单纯字段复用。
总结
这不是编译器的疏漏，而是 Go 团队基于可预测性、可读性与实现简洁性作出的深思熟虑的取舍。理解并接受这一限制，能帮助你写出更符合 Go 惯例、更易维护的代码。当看到 unknown field 错误时，请自然转向 嵌入类型名: { ... } 模式——它不是妥协，而是语言一致性的体现。
