在很多开发者的经验里，代码复用几乎总会联想到继承，但到了 Go 这里，这条路径被刻意弱化了。要理解 Go 为什么这样设计，关键不在于它“少了什么”，而在于它用结构体嵌入、接口隐式实现和小组件拼装，换来怎样的灵活性、封装性和维护成本优势。
继承为什么容易把代码带向僵化
在传统面向对象语言如 Java 和 C++ 中，继承通常是代码复用的主要方式。但继承建立的是一种强绑定的 is-a 关系，这种关系一旦在编译期确定，后续演进空间就会明显受限。
问题首先出在耦合上。父类和子类的设计被直接绑在一起，父类一旦调整，子类往往需要跟着改。业务变化越快，这种静态层级结构就越容易显得笨重。
其次是层次结构本身会不断膨胀。继承树一深，类型之间的职责边界就会变得模糊：哪些能力来自父类，哪些逻辑应该重写，哪些字段可以依赖，阅读和修改成本都会上升。等到新场景出现时，继承来的实现可能已经不再贴合实际，但要改动它，往往牵一发而动全身。
还有一个常见问题是封装被削弱。子类能够接触父类的保护字段和方法，这意味着父类内部实现细节更难自由调整。对外看像是在复用代码，对内却可能是把实现锁死在历史设计里。
Go 如何用组合替代继承
Go 选择的是另一条路：不强调“某个类型是另一个类型”，而是强调“某个类型拥有哪些能力”。这就是组合，也就是基于 has-a 关系来组织代码。
在 Go 里，最常见的组合方式就是结构体嵌入。你可以把一个已有类型直接嵌入到新类型中，让新类型获得对应的方法和字段访问能力，但这种获得能力的方式，并不会自动变成传统意义上的继承体系。
type Engine struct {
Horsepower int
}
func (e *Engine) Start() {
fmt.Println("Engine started")
}
type Car struct {
Engine // 嵌入Engine，获得Engine的所有方法和属性
Model string
}
func main() {
myCar := Car{Engine{150}, "Tesla"}
myCar.Start() // 直接调用嵌入类型的方法
}这段代码里，Car 通过嵌入 Engine 获得了 Start 方法，因此可以直接调用 myCar.Start()。但这里的含义是“车里有一个发动机”，而不是“车是发动机的一种”。
这也是 Go 设计的关键取向：把行为拆成更小、更专注的组件，再按需要拼到一起，而不是预先搭一棵复杂的类型继承树。
组合配合接口，Go 一样能完成多态
很多人第一次接触 Go 时会疑惑：没有继承，那多态怎么做？答案就是接口，而且是 Go 很有代表性的那种隐式实现接口。
在 Go 中，一个类型不需要显式声明自己实现了某个接口，只要它具备接口要求的方法集合，就可以被当成这个接口来使用。这样一来，多态能力仍然存在，但不再依赖继承层级。
type Drivable interface {
Drive()
}
type Car struct {
Engine
Model string
}
type Bike struct {
Brand string
}
func (c Car) Drive() {
fmt.Println("Driving", c.Model)
}
func (b Bike) Drive() {
fmt.Println("Riding", b.Brand)
}
func testDrive(vehicle Drivable) {
vehicle.Drive()
}这里的 Car 和 Bike 没有共同父类，但它们都实现了 Drive()，因此都能传给 testDrive。这说明 Go 的多态是围绕行为定义的，而不是围绕血缘关系定义的。
这种方式带来的直接收益，是类型之间的关系更松。你不需要为了让几个对象进入同一套调用链，专门抽出一个厚重的基类；只要它们满足同一份行为约定，就能协同工作。
从员工系统示例看，组合如何拼出不同能力
如果说前面的 Engine 和 Car 只是基础演示，那么员工管理系统这个例子更能体现组合的实际价值：不同角色可以复用部分能力，但又不必共享一整套僵硬的父类定义。
type Worker interface {
Work()
}
type Payable struct {
salary int
}
func (p Payable) GetSalary() int {
return p.salary
}
type Manageable struct{}
func (m Manageable) Manage() {
fmt.Println("Managing team")
}
type Engineer struct {
Payable // 嵌入Payable
}
func (e Engineer) Work() {
fmt.Println("Engineering work being done")
}
type Manager struct {
Payable // 嵌入Payable
Manageable // 嵌入Manageable
}
func (m Manager) Work() {
fmt.Println("Managerial work being done")
}这个模型里，Payable 负责薪资能力，Manageable 负责管理能力，Engineer 和 Manager 再根据各自职责把这些能力组合起来。
Engineer 只嵌入 Payable，说明它具备获取薪资的能力；Manager 同时嵌入 Payable 和 Manageable，因此既能拿到薪资，也能执行管理行为。至于两者的工作内容，则分别通过自己的 Work() 方法实现，并共同满足 Worker 接口。
这类设计的价值很直接：能力是拆开的，角色是按需组装的。以后如果增加 Contractor、TechLead 或其他岗位，不需要围绕某个“员工基类”做层层扩展，只要把需要的能力模块嵌进去，再补上自己的行为即可。
要点很重要：结构体嵌入并不等于继承
Go 的结构体嵌入很容易让初学者误以为它就是继承的替代写法，但两者本质并不一样。嵌入确实能带来方法提升和字段访问便利，可它不会建立传统 OOP 里的子类型关系。
下面这个例子最能说明问题：
type Polygon struct {
sides int
area int
}
type Rectangle struct {
Polygon // 嵌入Polygon
foo int
}
func main() {
var poly *Polygon = new(Rectangle) // 编译错误！
}这里 Rectangle 嵌入了 Polygon，但 *Rectangle 依然不能当成 *Polygon 使用，编译会直接报错。原因很简单：Go 不因为嵌入关系就认定“矩形是一种多边形对象实例，可以替代多边形指针”。
这正是 Go 与传统继承模型最明确的分界线。嵌入只是把一个类型作为另一个类型的组成部分，并提供语法层面的便捷访问；它不负责建立父子层次，也不制造自动的类型替代关系。
为什么 Go 更偏向组合这条路
更好的封装性
组合不会天然打破组件边界。外部对象获取的是组件暴露出来的能力，而不是任意深入其内部实现。这样一来，组件内部状态和实现细节更容易被保护住，后续重构空间也更大。
更高的灵活性
继承的关系通常在设计阶段就固定下来，而组合让能力可以按需拼接。面对新场景时，开发者更容易替换、增减或扩展某个组件，而不是推倒已有层级重新设计。
更简洁的结构
组合鼓励把职责拆小。类型本身不需要背负过多历史包袱，代码结构也不会随着层级加深而越来越难理解。对 Go 这种强调简单和可读性的语言来说，这一点尤其重要。
更弱的耦合关系
每个组件只处理自己的那部分职责，彼此之间通过清晰的接口和行为边界协作。这样的设计更利于测试、维护和局部替换，也更符合工程上“改一处不要牵动一片”的目标。
接口组合与使用场景：Go 的进一步表达能力
除了结构体组合，Go 还支持接口之间的组合。这一点让“能力拼装”的思路更加完整，因为接口本身也可以由更小的接口构成。
type Reader interface {
Read(p []byte) (n int, err error)
}
type Writer interface {
Write(p []byte) (n int, err error)
}
type ReadWriter interface {
Reader
Writer
}这里的 ReadWriter 并没有重新定义方法，而是直接组合了 Reader 和 Writer。这种做法鼓励接口保持小而专注，再在需要时组合出更完整的抽象。
从设计上看，这与 Go 一贯倡导的单一职责很一致：先定义足够小的能力边界，再根据业务需要把它们拼成更大的行为集合。
如果落到具体判断上，下面几类情况通常更适合优先考虑组合：
- 需要复用代码，但类型之间并不存在明确的
is-a关系。 - 希望行为能随着组件变化而调整，而不是被固定在单一层级里。
- 需要把多个不同来源的能力放进同一个对象中。
- 希望降低对象之间的耦合，让后续测试和维护更轻松。
这也是为什么 Go 会把“组合优于继承”做成一种近乎默认的工程倾向。它不只是语法选择，更是面向维护成本、演进能力和代码清晰度的一种取舍。
回到最初的问题，Go 并不是做不到继承式复用，而是有意避开了这套容易走向复杂化的设计。通过结构体嵌入、接口隐式实现和接口组合，Go 依然提供了足够强的复用与多态能力，同时把类型关系控制在更简单、更可演进的范围内。
对 Go 开发者来说，真正需要转变的不是某个语法习惯，而是设计思路：少去思考“我要从哪个父类扩展”，多去思考“我需要哪些小而清晰的能力组件，怎样把它们自然地组合起来”。
