优先用 interface 定义行为契约且无需共享状态或构造逻辑；必须用 abstract class 当需 protected 字段、构造器逻辑或模板方法。Java 8+ default 方法不改变本质差异：接口不能访问实例字段，且单继承多实现的约束不可替代。
什么时候该用 interface 而不是 abstract class
当需要定义一组行为契约，且不关心实现细节、也不需要共享状态或构造逻辑时，优先选 interface。Java 8+ 支持 default 和 static 方法，但它们不能访问实例字段——这恰恰划清了边界：接口只应描述“能做什么”，而非“怎么存数据”。
常见误用场景：
- 在
interface中声明public static final常量本无问题，但若开始往里塞配置类式的静态工具方法，说明职责已超界 - 为复用代码强行把多个无关类拉进同一个
abstract class继承树，结果导致子类被迫继承一堆用不到的字段和逻辑
典型适用案例：Comparable、Runnable、自定义的 PaymentStrategy —— 它们只约束行为签名，不携带状态。
什么情况下必须用 abstract class
当你需要提供可被子类直接复用的非静态字段、带逻辑的构造器、或者部分实现（尤其是涉及模板方法模式）时，abstract class 是唯一选择。
立即学习“Java免费学习笔记（深入）”；
关键判断点：
- 是否需要定义
protected字段供子类访问？→ 只能在abstract class中做 - 是否要强制子类走统一初始化流程（比如打开资源 + 校验参数）？→ 抽象类构造器可完成，接口做不到
- 是否已有类继承链，而新功能需插入共通逻辑？→ 接口无法修改已有继承关系，抽象类可通过重构父类注入
abstract class DataProcessor {
protected final Logger logger = LoggerFactory.getLogger(getClass());
protected String source;
protected DataProcessor(String source) {
this.source = Objects.requireNonNull(source);
init(); // 模板方法中的钩子
}
protected abstract void init();
public abstract void process();
}
Java 8+ 后 default 方法会不会让接口和抽象类越来越像
不会。表面相似，本质不同：
-
default方法不能访问this的非静态字段，所有实现仍必须各自维护状态 - 一个类只能
extends一个抽象类，但可implements多个接口——这是根本性差异，影响架构伸缩性 - 如果两个接口都提供了同名
default方法，实现类必须显式覆写，否则编译失败；而抽象类中方法冲突由继承层级自然解决
真实陷阱：有人用 default 方法模拟“轻量级抽象类”，结果在多实现组合时陷入菱形继承歧义，或因无法访问实例状态而反复传参，反而增加耦合。
Spring 或其他框架中常见的误判点
框架常模糊两者边界，容易误导设计决策：
-
@FunctionalInterface标记的接口（如Supplier）绝不能塞进字段或复杂逻辑，哪怕它只含一个抽象方法 - Spring 的
@Service类若同时实现多个接口，这些接口应纯粹表达能力（如UserRepository+Cacheable），而非承担数据模型职责 - MyBatis 的
Mapper接口是纯契约，但开发者有时会试图在其中加default方法做缓存封装——这违反了 Mapper 的单一职责，也绕过了 MyBatis 的代理机制
真正难的是：当业务模型既需要统一行为定义，又存在强状态依赖时，得靠组合代替继承——比如让具体类 implements 接口 + has-a 抽象基类提供的策略组件，而不是硬塞进一个大而全的抽象类里。
