Go没有继承只有组合，匿名字段是语法糖，将命名类型的可导出字段和方法提升到外层结构体，但不改变类型归属，也不支持方法覆盖或多态。
Go 没有继承，只有组合；匿名字段只是语法糖，不是“父类”或“基类”。理解这点，才能避免后续所有设计误用。
匿名字段到底做了什么
匿名字段在结构体中声明时省略字段名，Go 会自动把类型名作为字段名，并将该类型的全部可导出字段/方法“提升”到外层结构体上。这不是继承，是编译器帮你自动补全了访问路径。
常见错误现象：json.Marshal 时匿名字段的字段没被序列化、反射获取字段时看不到提升后的字段、嵌套匿名字段冲突导致编译失败。
- 匿名字段必须是命名类型（如
type Person struct{...}），不能是基础类型（如int）或未命名结构体字面量 - 多个同类型匿名字段会报错：
duplicate field Person，即使语义不同也不行 - 提升只作用于可导出标识符（首字母大写），
name string不会被提升，Name string才会 - 如果外层结构体已定义同名字段或方法，它会遮蔽匿名字段的对应项，且不会警告
组合继承的典型误用场景
开发者常把匿名字段当“父类”用，试图实现类似 OOP 的多态或重写。结果发现方法不能覆盖、interface{} 断言失败、指针接收者方法无法被提升——本质是混淆了“组合”和“类型归属”。
立即学习“go语言免费学习笔记（深入）”；
使用场景：构建可复用能力模块（如 Logger、Validator、Retryer），而非建模“is-a”关系。
- 方法提升仅发生在值接收者或指针接收者一致时：若匿名字段方法用
*Person接收者，只有外层结构体是*Outer类型时才能调用，Outer值类型调用会报错cannot call pointer method on ... - 没有虚函数表，不存在运行时方法分发；所谓“重写”只能靠显式字段覆盖或包装方法，比如在外部结构体里定义同名方法并手动调用匿名字段逻辑
-
fmt.Printf("%v", outer)默认打印包含匿名字段内容，但reflect.TypeOf(outer)返回的仍是外层结构体类型，和匿名字段无关
如何安全地模拟“继承行为”
真要接近 OOP 风格的行为复用，得靠接口 + 显式委托，而不是依赖匿名字段的自动提升。
示例：想让 Employee “拥有” Person 行为，又允许定制 String()：
type Person struct{ Name string }
func (p Person) String() string { return "Person: " + p.Name }
type Employee struct {
Person
ID int
}
func (e Employee) String() string { return "Employee(" + strconv.Itoa(e.ID) + "): " + e.Person.Name }
这里 Employee.String() 是全新定义，与 Person.String() 无覆盖关系；调用 e.Person.String() 依然有效，但 e.String() 总走自己的实现。
- 永远优先让业务逻辑明确：用
person Person显式命名字段，比Person匿名更易读、易调试、易重构 - 如果需要统一处理多个类型，定义接口（如
type Namer interface{ GetName() string }），再让各结构体分别实现，而非强求字段共享 - 嵌套层级超过两层（A 匿名含 B，B 匿名含 C）极易引发命名冲突和可读性灾难，应拆分为显式字段 + 辅助方法
匿名字段最危险的点在于：它让“谁提供了这个方法”变得模糊。调试时看到 e.Name 或 e.String() 调用，你得翻三遍源码才能确认来源——是本层定义？匿名字段 A？还是 A 的匿名字段 B？这种隐式链路，比多打几个字母写 e.Person.Name 代价高得多。
