Java类不能多继承但能多实现接口，是因为类继承涉及状态和具体实现，易引发字段冲突与方法歧义，而接口仅定义行为契约，无状态、无构造器，编译器可安全合并多个接口的抽象方法；默认方法冲突时须显式重写并指定调用X.super.m()或Y.super.m()。
Java 中接口可以多实现，是因为接口只定义行为契约，不包含状态或具体实现逻辑，编译器能安全地将多个 interface 的抽象方法合并到一个类中，而不会引发菱形继承、字段冲突或构造器歧义等问题。
为什么 Java 类不能多继承，但能多实现接口
Java 禁止类的多继承（即 extends 多个类），根本原因是避免「状态冲突」和「方法实现歧义」——比如两个父类都有同名 protected int count 字段或同签名的 void run() 方法，子类无法天然决定用哪个。
接口则不同：它默认所有方法是 public abstract，所有字段是 public static final，不参与实例状态管理。即使多个接口定义了同名默认方法（default），编译器也会强制你重写该方法来消除歧义。
- 类继承关注「是什么」（
is-a），涉及构造、字段、生命周期，必须唯一 - 接口实现关注「能做什么」（
can-do），只声明能力，可叠加 - 从 JVM 层看，
invokeinterface指令本身支持多接口方法查找，无需类层级上的继承树扁平化
接口多实现时 default 方法冲突的处理方式
当两个接口都提供了同签名的 default 方法（如 default void log() { ... }），实现类必须显式覆盖，否则编译报错：class A inherits unrelated defaults for log() from types X and Y。
立即学习“Java免费学习笔记（深入）”；
- 解决办法只有 1 种：在实现类中重写该方法，并可选择调用某个接口的默认实现，例如：
X.super.log()或Y.super.log() - 不能只写
super.log()—— 编译器不允许模糊调用 - 如果某接口的
default方法又调用了另一个接口的default方法，要注意循环依赖风险（虽不报错，但运行时可能栈溢出）
接口多实现与抽象类组合使用的典型场景
实际开发中，多接口 + 单抽象类是常见分层策略，比如网络客户端既要支持重试（Retryable）、又要支持熔断（CircuitBreakable）、还要统一日志（Loggable），但共享连接池和超时配置——这时让具体客户端类 extends AbstractHttpClient 并 implements Retryable, CircuitBreakable, Loggable 最自然。
- 抽象类负责「复用实现」和「共享状态」（如
protected ConnectionPool pool） - 接口负责「能力标签」和「解耦扩展」（如新增
Tracable接口不影响现有类结构） - 注意：抽象类里的方法若与接口
default方法同名，会直接覆盖接口行为，无需额外声明 —— 这是“类优先于接口”的规则
真正容易被忽略的是：接口多实现虽灵活，但一旦开始在接口里加 default 方法，就要小心语义漂移——它不再是纯粹的契约，而成了带行为的“轻量级抽象类”，此时应重新评估是否该拆出一个真正的抽象基类。
