Java接口不是多继承，而是以契约替代继承，只承诺行为不传递状态；混淆会导致设计僵硬、滥用default方法；应依“能力vs身份”选interface或abstract class。
Java 里没有多继承，interface 不是“实现多继承的途径”，而是用契约替代继承关系的方案。 它解决的是“能做什么”，不是“是谁”——这点混淆会导致设计僵硬、滥用 default 方法、误把接口当抽象类用。
为什么 interface 不能算多继承
Java 的类继承（extends）传递的是状态（字段）和行为（非私有方法），而 interface 只承诺行为签名（+ 可选的 default 或 static 实现）。一个类 implements 多个 interface，不获得任何父类字段，也不触发构造器链，更不会出现菱形继承问题——因为根本没继承“父类”。常见错误现象：Class A inherits conflicting default methods from B and C，这其实是编译期契约冲突，不是运行时继承冲突。
实操建议：
- 别在 interface 里定义
public static final常量来模拟“多重父类常量共享”，容易引发命名污染；改用独立的Constants类 - 当多个 interface 出现语义重叠（比如都含
save()和validate()），说明职责没切分清，优先重构接口粒度，而不是靠default强行统一实现 - 若真需要复用字段或复杂逻辑，用组合：让类持有一个
Helper实例，比塞一堆 interface 更可控
interface 中 default 方法的使用边界
default 方法本意是向后兼容（如 Java 8 给 Collection 加 stream()），不是让你写业务逻辑的后备选项。滥用它会让实现类失去对行为的完全控制，也掩盖了真正该由子类决定的策略。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 只在
default方法里放通用、无状态、低耦合的胶水逻辑，比如Objects.requireNonNull(this)校验或简单委托调用 - 避免在
default方法里访问实现类的私有字段或受保护字段——它做不到，强行绕会用反射，破坏封装 - 如果两个 interface 都提供了同名
default方法，实现类必须显式覆写，否则编译失败；这不是 bug，是语言强制你面对歧义
interface vs abstract class 的选择依据
看你要建模的是“能力”还是“身份”。比如 Runnable、Comparable、AutoCloseable 描述能力，适合 interface；而 AbstractList、HttpServlet 提供可复用的状态和骨架流程，适合 abstract class。
实操建议：
- 有构造逻辑、需要初始化字段、或想提供部分可被子类
super.xxx()调用的模板方法 → 选abstract class - 要被不相关的类（比如
String和自定义User）共同实现同一组行为 → 必须用 interface - Java 14+ 支持
sealed interface，但目前仍限于模块内有限实现，别指望靠它模拟“受控多继承”
最易被忽略的一点：interface 的方法默认是 public abstract，字段默认是 public static final——哪怕你漏写这些修饰符，编译器也会补上。很多人在 IDE 里删掉 public 觉得更简洁，结果导出 API 时被其他模块调用失败，只因误以为“没写就是包级可见”。
