Java用接口替代多继承，通过纯抽象契约（只定义方法签名）实现多维度能力组合，保持单继承清晰性；接口无状态、无构造器，避免菱形继承问题，default/static方法不破坏其行为契约本质。
Java 不支持多继承，但允许一个类实现多个接口，这是面向对象设计中“接口替代多继承”的核心机制。本质不是绕过限制，而是用契约（interface）而非实现（class）来复用行为规范，既保持单继承的清晰性，又获得多维度能力组合的灵活性。
接口只定义“能做什么”，不提供“怎么做”
接口是纯抽象契约，只声明方法签名，不含字段（除 static final 常量）和具体实现。多个接口可并存，因为它们彼此不冲突——没有构造器、没有状态、没有父类方法重写歧义。
- 例如：
Runnable约定“可运行”，Serializable约定“可序列化”，二者语义正交，一个类同时实现它们，只是承诺具备两种独立能力 - 编译器只检查是否实现了所有抽象方法，不关心这些方法在逻辑上是否“属于同一父类体系”
类仍保持单继承主线，避免菱形继承难题
Java 类只能有一个直接父类（如 extends Thread），确保方法解析路径唯一。若允许多继承，当两个父类都有同名方法时，JVM 无法确定调用哪个——这就是 C++ 中需显式指定作用域或虚继承解决的“菱形问题”。接口无此风险，因它不提供默认实现（Java 8 前），即使 Java 8+ 支持 default 方法，也规定：若类同时继承父类和实现接口，且三者存在同名方法，则优先级为 类自身 > 父类 > 接口；若多个接口提供同名 default 方法，必须由实现类显式重写，强制开发者决策。
default 和 static 方法让接口更实用，但不破坏本质
Java 8 引入 default 方法，看似“给接口加了实现”，实则仍是受限增强：
立即学习“Java免费学习笔记（深入）”；
- default 方法不能访问实例字段（无 this 指向具体对象状态），仅能调用其他 default 或 public 方法，本质是工具函数组合
- static 接口方法完全脱离实例，类似工具类，不参与多态分派
- 它们的存在是为了向后兼容（如
Collection新增stream()）和减少模板代码，未动摇“接口 = 行为契约”的定位
实际编码中，用组合+接口替代“伪多继承”需求
当业务感觉“需要继承多个父类功能”时，大概率是职责混淆。正确做法是：
- 把共性行为抽象为接口（如
Loggable、Validatable），让业务类implements它们 - 把复杂实现委托给内部组件（如
private Validator validator = new DefaultValidator();），通过组合复用逻辑，而非继承结构 - 必要时用适配器模式包装已有类，使其符合新接口，保持原有继承链不变
基本上就这些。接口替代多继承，不是语法妥协，而是引导你聚焦“对象能对外承诺什么”，而不是“它从谁那里抄了代码”。设计清晰了，多实现自然水到渠成。
