Java接口多继承安全，因只传递行为契约无实现；类多继承被禁以避免菱形歧义；默认方法冲突时强制显式覆盖，确保实现决策权在具体类。
核心矛盾：行为契约 vs. 实现复用
类继承传递的是具体实现——包括字段、方法体、构造逻辑。一旦多个父类提供同名方法或同名字段，子类就面临“选谁”的问题：调用时该走哪个父类的代码？编译器无法自动判断，运行时也无法安全推导。接口则只声明行为契约（方法签名），不带实现、不带状态。多个接口里有同名方法，对实现类来说不是冲突，而是统一承诺——你必须自己写一遍这个方法，结果完全由你控制。
菱形继承问题在类层级真实存在
假设类 B 和类 C 都继承自类 A，并各自重写了 A 的 run() 方法；类 D 同时继承 B 和 C。那么 D 调用 run() 时，该执行 B 版本还是 C 版本？Java 编译器直接禁止这种语法，从源头掐断歧义。而接口没有构造器、没有实例字段、没有可继承的方法体，即使接口 I1 和 I2 都声明了 run()，实现类 D 只需提供一个 run() 实现即可满足两者，不会产生调用路径模糊。
接口多继承是安全的扩展机制
接口支持 interface I3 extends I1, I2，这没问题，因为：
- 所有被继承的方法仍是抽象的，不引入任何实现逻辑
- 若 I1 和 I2 有相同方法签名，I3 不会因此报错，它只是叠加契约
- 真正要落地时，还是由最终实现类来统一覆盖，责任清晰
默认方法带来新约束，但未动摇设计根基
JDK 8 引入接口默认方法后，确实新增了潜在冲突场景：若类同时实现两个接口，且它们都为同一方法提供了默认实现，Java 要求该类必须显式重写这个方法，否则编译失败。这恰恰说明语言设计者坚持的原则没变——实现决策权必须落在具体类身上，绝不允许框架替你“猜”该用哪个默认版本。这种强制覆盖，反而是单继承多实现原则更严谨的体现。
立即学习“Java免费学习笔记（深入）”；
