该用 abstract class 而不是 interface 的情况是：需共享代码逻辑、定义部分实现或强制子类继承特定类层级时；因 Java 不支持多继承，一个类只能继承一个抽象类，却可实现多个接口。
什么时候该用 abstract class 而不是 interface
当需要共享代码逻辑、定义部分实现、或强制子类继承某个类层级时，选 abstract class。Java 不支持多继承，但一个类只能 extends 一个抽象类，却能 implements 多个接口——这是最根本的取舍前提。
常见误用是：为“定义行为”而硬写抽象类，结果导致后续扩展卡死。比如设计日志组件，若已有 BaseLogger 封装了通用格式化、异步写入逻辑，且所有子类都应基于它构建，那就适合抽象类；但如果只是约定“能记录、能关闭”，那 interface Logger 更轻量、更灵活。
-
abstract class可含构造器、成员变量（protected或包级）、静态方法、具体方法（非default）、甚至main方法 - 接口不能有构造器，字段默认是
public static final，方法默认是public abstract（Java 8+ 支持default和static，但仍是契约导向） - 如果未来可能要加新方法，又不想破坏现有实现，
interface加default方法比抽象类加新抽象方法更安全
Java 8+ 接口里 default 方法的真实用途
default 方法不是为了替代抽象类，而是为接口演进提供向后兼容能力。它解决的是“老接口加新功能，不强制所有实现类改代码”的问题，不是让你把业务逻辑塞进去。
典型反模式：在接口里写一堆 default 方法，封装完整流程（比如 process() 调用 validate() → transform() → save()），这会让接口失去契约性，也掩盖了真正的职责归属。
立即学习“Java免费学习笔记（深入）”；
- 只对真正通用、极少被重写的辅助逻辑用
default（如Collections.sort()的包装、空集合判空工具逻辑） - 避免在
default方法中调用其他default方法形成隐式依赖链 - 如果
default方法需访问状态，说明这个行为本该属于具体类或抽象类——接口不该持有状态
抽象类与接口混用的合理场景
真实项目里经常两者并存：抽象类提供骨架实现，接口定义能力契约。例如 Spring 的 AbstractController（抽象类）负责请求生命周期管理，而它同时实现 InitializingBean、DisposableBean（接口）来接入容器生命周期钩子。
这种组合的关键在于分层清晰：抽象类管“怎么做”，接口管“能做什么”。混淆会导致继承树臃肿、语义模糊。
- 一个类可以
extends AbstractService+implements Serializable, Cloneable—— 前者是实现复用，后两者是能力声明 - 不要让抽象类去实现多个业务接口（如
extends AbstractUserManager implements OrderProcessor, ReportGenerator），这会让抽象类承担过多正交职责 - 如果发现抽象类里大量方法只是抛
UnsupportedOperationException，说明它其实该拆成多个接口 + 更小粒度的抽象基类
编译期与运行期差异带来的坑
接口方法调用走的是虚拟机的接口调用指令（invokeinterface），抽象类方法是普通虚方法调用（invokevirtual）。性能差异极小，但反射或字节码操作时行为不同——比如 Method.getDeclaringClass() 对 default 方法返回的是接口类，对抽象类方法返回的是抽象类本身。
更实际的问题是默认方法冲突：当一个类同时实现两个接口，它们都有同签名的 default 方法，编译直接报错，必须在子类中显式覆写。而抽象类不会出现这种“多源默认实现”冲突。
- 使用 Lombok 的
@EqualsAndHashCode时，若类实现了带default方法的接口，Lombok 不会自动处理接口方法，别指望它帮你生成基于接口契约的相等逻辑 - Mockito 3.4.0+ 才支持 mock
default方法，旧版本 mock 接口时这些方法会被忽略，可能导致测试通过但运行时报UnsupportedOperationException - 序列化时，接口不参与，但抽象类的可序列化字段和
readObject等钩子会生效——这点常被忽略，尤其在 RPC 场景下
