Go 和 Rust 都故意不提供传统的类继承（class inheritance），核心原因高度一致：继承虽然看起来方便，但长期来看它带来的问题往往大于它解决的问题。两门语言的设计者都把“组合优于继承”（Composition over Inheritance）当作重要的设计原则，并通过语言机制强制或强烈引导开发者往这个方向走。
下面从实际痛点、设计哲学和语言提供的替代方案三个维度来拆解为什么它们选择“舍弃”继承。
1. 继承在大型项目中真正带来的主要问题（也是被舍弃的主因）
| 问题类型 | 继承带来的典型表现 | 为什么在现代大规模工程中很致命 | Go / Rust 亲身经历的教训来源 |
|---|---|---|---|
| 紧耦合 & 脆弱基类问题 | 子类严重依赖父类实现细节，改父类容易炸子类 | 父类一改动，整个继承树都可能需要修改或重测 | C++ / Java 大型代码库的真实灾难 |
| 菱形继承 / 多重继承地狱 | 多继承导致命名冲突、虚继承、内存布局复杂 | 调试和理解成本爆炸 | C++ 的历史包袱 |
| 语义不清晰（is-a vs has-a 滥用） | 把“has-a”关系错误地写成“is-a”继承 | 领域模型扭曲，后期重构极难 | Java / C# 企业项目常见反例 |
| 实现继承 vs 接口继承混淆 | 同时继承行为和数据，难以单独复用行为 | 代码复用方式单一且不灵活 | 传统 OOP 框架的通病 |
| 测试 / Mock 困难 | 子类紧绑父类实现，单元测试很难 mock 父类行为 | TDD / 测试覆盖率难以推进 | Go 社区特别强调这一点 |
| 性能 & 内存布局不可预测 | 虚函数表、对象 slicing、多重继承内存布局复杂 | Rust 尤其在意零成本抽象和可预测性 | Rust 内存安全 + 性能双目标 |
一句话总结：继承是“纵向复用”，但它把复用和“类型层次”强绑定在一起，导致耦合度过高、灵活性过低。
2. Go 和 Rust 分别用什么机制替代继承（它们其实殊途同归）
| 语言 | 替代继承的核心机制 | 怎么实现“类似继承”的效果 | 强制/引导程度 |
|---|---|---|---|
| Go | 匿名嵌入（struct embedding） + 接口 | 把一个结构体匿名嵌入另一个结构体 → 自动获得其方法（委托） 接口实现“鸭子类型”多态 | 非常强（根本没类和继承语法） |
| Rust | Trait + 泛型 + 组合（struct 嵌套） | 用 Trait 定义行为 用泛型 / impl 为具体类型实现 Trait 数据直接组合（has-a） | 极强（连 class 关键字都没有） |
两者共同点：
- 行为复用 → 通过接口 / trait（横向的、松耦合的）
- 数据复用 → 通过组合（把需要的字段直接嵌进去）
- 不存在“父类引用指向子类对象”的隐式向上转型（Go 接口值、Rust dyn Trait 才有动态分发）
3. 设计者公开表达过的核心动机（提炼版）
- Go（Rob Pike 等）
“我们观察到，大型面向对象系统中，继承链越长，维护成本越高。我们想要简单、可预测、可组合的语言。接口 + 嵌入已经足够表达绝大多数需求，而且更清晰。” - Rust（Graydon Hoare 等早期设计者）
“继承与 Rust 的内存模型、安全模型、零成本抽象目标严重冲突。虚函数表 + 对象布局继承会破坏所有权、生命周期、Send/Sync 等安全保证。组合 + trait 能达到甚至超过继承的表达力，同时保持可预测的性能和安全性。”
4. 一个极简对比表（实际使用感受）
| 你想实现的效果 | 用继承（Java/C#风格）怎么写 | 用 Go 风格写 | 用 Rust 风格写 | 谁更清晰/灵活？ |
|---|---|---|---|---|
| “汽车是交通工具” | class Car extends Vehicle | type Car struct { Vehicle } | struct Car { vehicle: Vehicle } | Go/Rust 更明确是 has-a |
| 添加“可飞行”能力 | class FlyingCar extends Car implements Flyable | 再嵌入 Flyable struct 或实现 Flyable 接口 | impl Flyable for Car { … } | Trait 胜出 |
| 替换引擎实现（mock 测试） | 很难（紧耦合父类） | 很容易（组合可以换掉字段） | 很容易（依赖注入 + trait object） | 组合完胜 |
小结
Go 和 Rust 舍弃继承，不是因为它们“不支持面向对象”，而是因为它们认为传统的类继承是一种过时的、弊大于利的代码复用方式。
它们用更松耦合、更可组合、更可测试的机制（接口/trait + 组合）来取代继承，在实际大型项目中表现出了更高的长期可维护性和更低的意外复杂度。这也是为什么“组合优于继承”这句话从 90 年代的建议，变成了 2020 年代很多现代语言的强制设计选择。
你现在写代码时，是更倾向于用继承，还是已经习惯组合 + 接口/trait 的写法了？
