Go 语言虽然不提供传统意义上的继承机制，但通过结构体嵌入与接口组合，同样能够实现代码复用、易于测试且低耦合的设计。核心思路并非模拟父类，而是将共性逻辑抽象提取，将变化点交由外部定义。以下是一些关键认知：嵌入并非继承，接口并非抽象类，依赖注入才是实现真正解耦的有效手段。
结构体匿名嵌入（embedding）的正确使用方式与常见陷阱
匿名嵌入的基本原理是让外层结构体“自动获得”内层结构体的所有字段与方法。然而，在实际开发中，初始化、指针接收者、字段冲突等环节若处理不当，极易引发问题。
- 嵌入必须采用无字段名的类型声明，例如直接写
Base，而非b Base。后者属于命名嵌套，不会触发字段与方法的提升，两者语义完全不同。 - 一个容易踩坑的细节：若
Base的方法使用指针接收者（如func (b *Base) GetID() int），则只有在外层结构体取地址后才能调用。直接写e.GetID()会编译报错，需写成(&e).GetID()。许多初学者初次接触时容易在此处出错。 - 当多个嵌入结构体包含同名字段或方法时，Go 并不会自动合并或覆盖，而是直接报编译错误。例如，若
A和B都定义有ID字段，那么type C struct { A; B }将无法通过编译。 - 嵌入结构体的字段标签（如
json:"id"）会保留，但需注意优先级：若外层也定义了同名字段，则标签以外层为准。
接口定义行为契约时，为何不能包含字段
Go 的 interface 只能声明方法签名，不允许包含字段或具体实现。这并非设计缺陷，而是刻意为之——它强制开发者将“数据”与“行为”分离管理，避免状态与逻辑混杂在一起。
- 错误示例：
type Foo interface { Name string; Do() }→ 编译失败，因为string不是方法。 - 正确的做法是：用结构体承载字段（例如
Base），用接口约束行为（例如Describer），两者通过组合协作。 - 接口应尽量小巧。拆分为
Validator、Logger、Serializer等小接口，远比一个大而全的BaseInterface更具灵活性。否则实现方被迫实现大量用不到的方法，反而增加了耦合度。
依赖注入比循环引用更安全
有一种常见的反模式：让 Base 持有子类型接口，然后在子类型中将自己赋值给 Base 的字段（如 e.Base.B = &e）。这看似实现了“父类调用子类”的效果，实则埋下了 panic 的风险。
- 零值时
e.Base.B为nil，调用e.Base.SomeMethod()会直接引发 panic。 - 并发初始化时，可能出现
Base尚未构造完成，而e已经开始调用其方法的情况。 - 单元测试极为困难：无法单独 mock
Base的行为，因为其逻辑强依赖于子类型实例。 - 推荐的做法是通过构造函数显式注入，例如
NewUser(logger Logger, validator Validator)。这样Base只持有接口字段，不参与生命周期管理，职责清晰，测试也更方便。
嵌入结构体与命名字段嵌套的实际差异
两者都属于“组合”范畴，但语义与使用方式截然不同。选择错误会导致 API 难以使用、序列化异常、后续升级脆弱。
- 匿名嵌入（
Base）→ 字段和方法被“提升”，User.Name、User.GetID()可直接访问；JSON 序列化时字段平铺（除非显式忽略）。 - 命名嵌套（
Addr Address）→ 必须写u.Addr.City；JSON 默认生成嵌套对象{"addr": {"city": "Beijing"}}。 - 嵌入结构体不能重复嵌入同一类型（编译报错），但命名字段可以（例如
Home Address,Work Address）。 - 如果目标仅是复用一组字段，并不希望暴露方法，则使用命名字段；如果要复用字段+方法+行为，则使用匿名嵌入。
真正考验开发者的并非语法本身，而是判断哪些内容应放入嵌入结构体、哪些应抽成接口、哪些应由调用方传入。每次新增字段或方法前，先问自己：这个元素是否会被其他类型复用？它是否应独立于当前业务逻辑存在？答案将帮助你决定是使用 Base、Describer，还是干脆放弃抽象。
