Java只支持单继承，是设计者主动选择“类单继承+接口多实现”以规避多重继承的歧义与复杂性；接口无状态、只声明能力，同名方法须由实现类明确提供逻辑，保障语义清晰与静态可验证性。
Java只支持单继承，不是因为技术上做不到，而是设计者主动选择用“类单继承 + 接口多实现”来规避多重继承固有的歧义与复杂性。这种取舍直指运行时确定性和工程可维护性，而非语法自由度。
菱形问题无法在编译期消解
当一个类试图同时继承两个父类，而这两个父类又共享同一祖先时，方法调用路径就不再唯一。比如A定义了speak()，B和C各自重写了它，D若能extends B, C，那么d.speak()该走哪条路？JVM没有内置规则自动裁决，编译器也无法推断开发者意图——这不是缺算法，而是缺明确语义。
- 这种歧义不是理论假设，C++靠虚继承等机制硬扛，但代价是对象内存布局不可预测、构造顺序难追踪、this指针需动态调整
- Java拒绝把这类决策留给运行时或隐式规则，直接在语法层禁止，让方法解析路径始终唯一、可静态验证
字段与状态冲突无解
类继承携带的是完整状态（实例字段）和行为（方法），多个父类若定义同名字段（如protected int id），子类访问super.id时根本无法确定指向哪个父类的副本。这不同于接口——接口没有实例字段，只有常量和方法契约。
- 字段冲突不是编译警告，而是语义断裂：同一个变量名代表不同内存位置，破坏封装和可读性
- 即使强制规定“就近继承优先”或“声明顺序优先”，也会让代码行为依赖书写顺序，违背“显式优于隐式”的设计信条
接口多实现才是真正的替代方案
Java允许一个类implements多个接口，这不是妥协，而是更干净的建模方式：接口不携带状态，只声明能力；同名方法必须由实现类亲自提供逻辑，不存在“继承哪个”的模糊地带。
立即学习“Java免费学习笔记（深入）”；
- JDK 8 后接口支持default方法，但若多个接口提供同签名default，编译器强制要求子类重写——把选择权交还给开发者，而非交给语言规则
- 接口之间可以extends多个接口，这是纯类型合并，不涉及运行时对象结构变化，零开销且完全安全
单继承保障整个生态的稳定性
从字节码验证、JVM类加载到IDE智能提示、序列化框架支持，单继承让整个工具链有稳定假设：类图是一棵树，方法查找路径唯一，LSP（里氏替换原则）可机械验证。
- 多重继承会让类图变成有向无环图甚至带环图，静态分析工具难以准确推断类型兼容性
- 企业级项目动辄数千个类，继承链一旦失控，重构、mock测试、依赖注入都会变得脆弱且高风险
