接口用于定义“能力契约”，解决跨模块协作、多能力组合、策略切换与回调通知；抽象类用于表达“身份归属”，解决骨架复用、流程固化、protected复用及初始化约束。
接口和抽象类不是“选哪个更好”，而是“解决哪类问题”。设计架构时，关键看你要建模的是“身份归属”还是“能力契约”。
当系统需要定义统一能力规范时，优先用接口
接口的核心语义是“能做什么”，它不关心实现者是谁、内部状态如何，只约定行为边界。适合以下场景：
-
跨模块或跨团队协作：比如订单服务要调用支付服务，定义一个
PaymentService接口，微信、支付宝、云闪付各自实现，上层完全解耦； -
同一对象具备多种独立能力：如一个文件处理器既要可读（
Readable）、又要可写（Writable）、还要可关闭（Closeable），这些能力无继承关系，只能靠多实现接口组合； -
策略切换与Mock测试：业务逻辑依赖
RuleEngine接口，开发时用内存版，测试用Mock版，上线切真实风控引擎，替换成本极低； -
回调与事件通知：如
OrderEventListener，多个模块监听订单状态变更，彼此不耦合，也不需要共享字段或流程。
当系统需要复用骨架逻辑与共享状态时，用抽象类
抽象类的核心语义是“它是什么”，强调血缘关系和代码复用。适合以下场景：
-
同族类型有共性字段和初始化逻辑：比如
AbstractUser含id、createdAt、status等通用属性，并在构造器中完成基础校验； -
主流程固定、子流程可变：报表导出统一走“加载→转换→输出”，但Excel、PDF、CSV三者的每步实现不同，用模板方法模式，在抽象类中固化流程，留
doLoad()、doExport()等钩子； -
需要 protected 方法或字段供子类复用：比如
AbstractHttpClient提供buildRequest()（protected）和重试工具类，子类可直接调用，接口无法做到； - 强制子类遵守初始化约束：抽象类可带参构造器，确保每个子类创建时都传入必要上下文（如租户ID、配置对象），接口做不到这点。
避免常见误用陷阱
很多架构问题源于混淆设计意图：
立即学习“Java免费学习笔记（深入）”；
- 别在接口里塞大量 default 方法：一旦接口承担了太多实现职责，就模糊了“契约”本意，后期扩展反而更僵硬；
-
别用抽象类代替接口做跨域依赖：比如把
UserService设计成抽象类，下游模块就得继承它，失去替换灵活性，也违背依赖倒置原则； - 别为了“复用一点逻辑”强行上抽象类：若只是几个工具方法，用普通工具类 + 静态方法更轻量；若只有行为共性，接口 + 默认方法已足够；
- 接口不能存实例状态，抽象类可以——这个差异决定数据归属：需要维护连接池、缓存引用、线程上下文？只能放抽象类里。
协同使用才是高阶实践
真实项目中，二者常配合出现：
- 支付系统中，
PayChannel是接口，定义pay()、refund()； - 而微信、支付宝各自的 SDK 封装，可各自继承
AbstractPayClient（含签名生成、HTTP 调用、异常转换等通用逻辑）； - 最终业务层面向
PayChannel编程，运行时注入具体实现，既解耦又复用。
这种“接口定边界、抽象类给骨架”的分层，才是稳定可演进的架构底座。
