接口是公开、抽象、可组合的行为契约，表达“能力”而非“身份”，支持多实现与向后兼容演进；abstract class 表达纵向类型继承，仅单继承。
接口不是类，是契约的语法载体
Java 中的 interface 本身不能被实例化，也不包含状态（字段只能是 public static final），更不提供默认实现（除非用 default 或 static 方法）。它的本质是一组**公开、抽象、可组合的行为约定**——编译器强制实现类必须提供这些方法的具体逻辑，但不管你怎么实现。
这种设计让接口天然适合表达「能力」而非「身份」。比如一个类可以同时 implement Comparable 和 Serializable，这不是在说“它是什么”，而是在声明“它能做什么”和“它支持什么协议”。
interface 和 abstract class 的关键分界点
二者都支持抽象方法，但语义和用途完全不同：
-
interface表达的是横向能力扩展，支持多继承（一个类可实现多个接口）；abstract class是纵向类型继承，只允许单继承 - 接口中所有方法默认是
public abstract，字段默认是public static final；抽象类可含protected方法、构造器、非 final 字段 - 从 Java 8 起，接口可带
default方法（提供默认行为，不破坏已有实现），但无法拥有实例状态；抽象类的default行为天然可访问this和成员变量 - 序列化、反射、代理等运行时机制对两者的处理路径不同：比如
Proxy.newProxyInstance()只接受接口列表，不接受抽象类
default 方法不是“退让”，而是演进机制
给已有接口添加新方法会导致所有实现类编译失败。Java 8 引入 default 方法，就是为了解决接口的**向后兼容演进问题**。但它不是让你把接口当抽象类用：
-
default方法应仅提供通用、无状态、不依赖实现细节的逻辑（如集合操作的stream()、forEach()） - 避免在
default方法里调用其他default方法形成隐式依赖链 - 若实现类需要差异化逻辑，仍应重写该方法；不要靠层层
super.xxx()堆叠行为 - 注意
default方法无法访问private成员（接口里不允许定义private实例字段）
public interface EventProcessor {
void handle(Event e);
default void batchHandle(List events) {
events.forEach(this::handle); // 安全：只调用自身已承诺的抽象方法
}
}
接口设计中最容易被忽略的约束点
很多团队把接口写成“方法大杂烩”，结果导致实现类负担过重或语义模糊。真正关键的约束不在语法，而在设计意图：
- 一个接口应遵循 单一抽象职责：比如
Runnable只管执行，Callable只管执行并返回，不混在一起 - 方法签名要稳定：参数尽量用接口或不可变类型（如
Collection而非ArrayList），避免因具体实现变更被迫改接口 - 慎用泛型接口的类型擦除副作用：比如
Consumer和Consumer在运行时是同一个类型，无法做instanceof判断 - 模块化项目中，接口应定义在调用方可见、但实现类不可见的包里（典型的 API 模块与 SPI 模块分离）
接口一旦发布，修改成本远高于类——哪怕加一个 default 方法，也要考虑老实现是否意外覆盖了同名方法，或子类是否因多继承产生 default 冲突。
