Java类不支持多继承是明确的设计选择，旨在避免菱形继承导致的方法调用与字段歧义；接口可多实现，因其无状态且default方法冲突时须显式覆写。
Java 不支持类的多继承，不是语法疏漏，而是明确的设计选择：一个类只能用 extends 继承一个父类（无论是否抽象），编译器会直接拒绝多个 extends。这背后不是技术做不到，而是为了确保代码行为可预测、演化安全、工具链稳定。
核心限制：菱形继承问题无法无歧义解决
当两个父类都继承自同一个祖先，又各自重写了同名方法时，子类调用该方法就面临“该走哪条路径”的根本性困惑。JVM 的方法解析依赖线性继承链（getSuperclass() 返回唯一父类），无法在编译期或运行时自动裁决语义意图。C++ 用虚继承等机制硬扛，但代价是构造顺序难控、内存布局复杂；Java 选择从源头禁止，让调用路径始终唯一、静态可验证。
字段与状态冲突不可绕过
类继承携带的是完整状态——实例字段、初始化逻辑、访问控制。如果两个父类都声明了 protected int id，子类中写 super.id 就无法确定指向哪个副本。这不是命名警告，而是语义断裂：同一变量名对应不同内存位置，破坏封装和可读性。接口没有实例字段，天然避开这一问题。
接口才是为“能力组合”设计的正确机制
Java 允许一个类 implements 多个接口，这不是妥协，而是语义更清晰的建模方式：
立即学习“Java免费学习笔记（深入）”；
- 接口表达“能做什么”（can-do），不承载“是什么”（is-a）的层级关系
- 所有方法默认抽象，JDK 8+ 的
default方法若签名冲突，编译器强制要求实现类显式重写——把决策权交还给开发者 - 接口之间可以
extends多个接口，纯类型合并，零运行时开销
真正推荐的替代实践：组合优于继承
当需要复用多个有状态、有行为的模块时，优先采用组合：
- 把“能飞”“能游”等功能封装成独立类（如
FlyBehavior、SwimBehavior） - 在主类中以字段持有，并通过接口定义委托契约
- 运行时可替换具体实现，比编译期继承更灵活，也避免脆弱基类问题
