为什么 C# 放弃了多类继承？

TL;DR：多重继承的添加增加了很多复杂性并且使用起来几乎没有好处。

翻译Chris Brumme 对 Why doesn't C# support multiple inheritance? 的回答？

我们没有直接实现多重实现继承有几个原因。（如您所知，我们支持接口的多重继承）。

但是，我应该注意到，编译器可以在 CLR 中为其类型创建多重继承。这条路线有几个问题：结果无法验证，无法通过CLS与其他语言进行互操作。一种在 RVA 静态字段中创建一些 VTable 的技术。要处理托管方法（甚至可能还没有进行 JIT 处理），您可以使用 VTFixup 构造。这个结构是一张三元组表。三元组由托管方法的句柄、需要提交的映像中的地址（在本例中，您在 RVA 静态字段中创建 VTable 槽）和一些标志组成。corhdr.h中描述了可能的标志. 它们允许您指定指针的大小：32 位与 64 位，控制虚拟行为，以及是否有任何反向 PInvoke 模式应该以延迟评估的形式应用，最终传递给托管方法. 如果我们执行unmanaged->managed transition ，我们还可以控制选择哪个 AppDomain 来发送调用。

我们没有提供一个深思熟虑的、可验证的、符合 CLS 的多实现继承版本的原因有几个：

1. 不同的语言对多重继承的工作原理有不同的期望。例如，如何解决冲突以及是否合并或丢弃重复项。在我们可以在 CLR 中实现多重继承之前，我们必须回顾所有的语言，定义共同的概念，并决定如何以中立的方式表达它们。我们必须决定多重继承是否会出现在 CLS 中，以及它对于不想支持这个概念的语言（比如 VB.NET）意味着什么。当然，这是我们在 CLR 中的工作，但我们还没有找到时间为多重继承做这件事。

2. 实际上很少有地方可以很好地使用多重继承。在许多情况下，接口的多重继承是可行的。在其他情况下，您可以使用封装和委托。如果我们要添加另一个结构，比如 mixins，哪个会更强大？

3. 多重实现继承增加了实现的复杂性。这种复杂性会影响转换、序列化、字段访问、反射以及可能的许多其他地方。

目前还不完全清楚这个机会是否会有所回报。这是我们经常问自己的问题。这是我们还没有完全测试过的东西。但我的直觉告诉我们，经过深入分析，我们将决定不添加此功能。