<p>C#接口支持多继承而类只允许单继承，以避免菱形继承歧义；接口多继承仅叠加契约，无实现冲突；类需用显式实现或默认接口方法（C# 8+）处理多接口成员，但须手动解决同名方法二义性及履约完整性。</p>
接口可以多继承，但类不能多继承
C# 的 interface 支持多继承，这是它和 class 的关键区别。你写 interface IA : IB, IC 完全合法；但写 class A : B, C 就会报错 CS0246 —— 编译器直接拒绝。
原因很简单：C# 为避免菱形继承带来的歧义（比如两个父类都有同名方法，子类该调谁的？），只允许单继承 class，把“组合能力”让渡给 interface。
- 接口多继承只是声明契约叠加，不带实现，没有二义性风险
- 类继承是“is-a”关系，语义上天然排斥多个确定父类型
- 如果你真需要复用多个行为，用 interface + 显式实现 或
default interface method（C# 8+）更安全
显式实现接口时，多继承容易漏掉方法
当一个类同时实现多个有重名成员的接口（比如 IA 和 IB 都定义了 void Run()），又用显式实现写法，很容易只写一个 void IA.Run()，忘了 void IB.Run()，结果编译报错 CS0535：“‘X’ does not implement interface member ‘IB.Run()’”。
这不是语法错误，而是契约没履约到位。编译器强制你逐个兑现每个接口声明的成员。
- 显式实现必须完整覆盖所有继承链上的抽象成员，包括从父接口间接继承来的
- 用 Visual Studio 或 Rider 的“实现接口”快捷键（
Ctrl+.）能自动生成骨架，但要注意检查是否遗漏间接继承项 - 如果两个接口的同名方法语义一致，可统一用一个显式实现，再在另一个接口里用
void IB.Run() => ((IA)this).Run();转发
默认接口方法（C# 8+）让多继承“像有实现”，但有陷阱
C# 8 引入了 default interface method，看起来像给接口加了“默认实现”，于是有人以为能靠它模拟多继承逻辑复用。但实际很脆弱：一旦两个父接口都提供了同名默认方法，子类不显式实现就会触发编译错误 CS8705 —— “无法推断默认实现”。
这不是 bug，是设计限制：编译器拒绝自动选边站队。
- 默认方法仅用于提供向后兼容的“可选实现”，不是替代类继承的机制
- 若父接口 A 和 B 都定义了
string GetName() => "A"和string GetName() => "B"，子类必须自己写public string GetName()消除歧义 - 运行时调用行为也受变量静态类型影响：用
IA x = new C()调x.GetName()，走的是 A 的默认实现；换成IB y = new C()，走的就是 B 的
用组合代替多继承时，别直接 public 字段暴露实现
很多人想绕开继承限制，就写一个类聚合多个服务对象，比如：public IA _a; public IB _b;。这看似灵活，但立刻带来两个问题：外部代码可随意改字段值，破坏封装；且无法通过接口统一约束行为入口。
真正可控的做法是把依赖作为 private readonly 字段，再通过当前类的公共方法做协调转发。
- 不要暴露内部服务实例，否则使用者可能绕过你的业务逻辑直接调用底层
_a.DoSomething() - 如果多个接口方法逻辑高度耦合（比如
Start()必须先调_a.Init()再调_b.Connect()），就在当前类里封装成一个原子方法 - 考虑用
required属性（C# 11+）或构造函数注入来确保依赖不为空，避免运行时NullReferenceException
事情说清了就结束。接口多继承本身不难，难的是人在“想复用”时容易高估默认方法的能力，低估显式实现的履约成本。
