Java类不支持多继承，仅允许单继承，这是编译期语法限制；接口可多实现并支持default方法，但同名default方法需显式解决冲突；组合优于继承，尤其涉及状态时。
Java类确实不能多继承，编译器会直接报错
当你写 class Duck extends Bird, Animal，JDK 立刻拒绝：编译错误 java: class Duck inherits from both Bird and Animal（实际错误信息常为 java: types Bird and Animal are incompatible 或更直白的 java: duplicate class）。这不是 JVM 运行时限制，而是语法层面的硬性封禁——没有“绕过”这回事。
根本原因不是怕你写错，而是怕歧义无法自动消解：比如 Bird 和 Animal 都定义了 void breathe()，Duck 调用时该走哪份实现？C++ 用虚继承补救，Java 选择一刀切，把问题消灭在编译期。
- 接口可以多实现，类只能单继承——这是 Java 类型系统的基石分界线
- 抽象类也不行：
abstract class A extends X, Y同样非法 - 内部类“模拟多继承”只是障眼法：外部类仍单继承，内部类的父类对它而言是独立作用域，不改变继承拓扑
用 interface + default 方法组合行为最常用也最安全
Java 8 起，interface 支持 default 方法，让“能力复用”真正落地。一个类 implements Flyable, Swimmable，就能天然拥有 takeOff() 和 dive() 的默认实现，无需重复写样板代码。
但要注意：多个接口提供同名 default 方法时，编译器不会帮你选，必须显式解决冲突。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 必须重写该方法，哪怕只转发给某一方：
Flyable.super.takeOff()或Swimmable.super.takeOff() - 不能写
super.takeOff()——编译器不知道你要调谁的 - 如果其中一个是抽象方法（无
default），那它优先级更高，实现类必须提供具体逻辑 -
static方法不参与冲突解析，调用必须带接口名：Flyable.honk()
需要状态或构造逻辑时，组合比继承更可靠
当“能飞”不只是个动作，还涉及翼展、升力系数、燃油余量等私有字段，default 方法就撑不住了。这时候强行塞进接口，等于把状态和行为耦死在契约里。
组合方案是把能力封装成独立类，通过成员变量持有，并由接口定义委托契约：
- 避免
fragile base class problem：父类改个构造参数，所有子类全崩 - 运行时可切换行为：
bird.setBehavior(new JetEngine())比改继承关系快得多 - 符合
Effective Java第16条：“Prefer composition over inheritance” - 测试友好：可 mock
FlyingBehavior，不用动Bird类本身
接口多继承（extends 多个接口）是合法但需警惕默认方法叠加
接口本身支持多继承：interface Duck extends Flyable, Swimmable, Quackable 是完全合法的。但它不是“多重父类”，只是声明合并——所有方法签名被拉平到同一命名空间。
真正的坑在默认方法叠加：
- 若
Flyable和Swimmable都有default void start()，Duck接口必须重写它，否则编译失败 - 子接口重写时，可用
Flyable.super.start()显式调用某一方，也可全新实现 - 这种约束其实是好事：它强迫你在设计层面对“同名能力”的语义做澄清，而不是留到实例类里再猜
真正复杂的地方不在语法，而在于建模时要不要把“能飞”“能游”“能叫”拆成三个接口——这取决于它们是否真的正交、能否独立演化。一旦开始纠结“哪个接口该放哪个方法”，说明你已经踩进领域建模的深水区了。
