为什么go和rust语言都舍弃了继承？

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）	组合完胜