接口定义模块间契约，支持多实现与运行时插拔；抽象类封装域内共性逻辑与流程骨架；二者分层协作支撑系统演进。
在高级架构设计中，接口与抽象类的差异不是语法细节的堆砌，而是系统分层、职责划分和演进弹性的底层支撑。它们各自扮演不可替代的角色：接口定义边界契约，抽象类固化核心流程。
接口是模块间“协议层”的基石
大型系统常按领域拆分为独立服务或模块（如订单服务、支付服务、用户中心）。这些模块之间不共享实现，只约定交互方式——这正是接口的核心价值。
- 对外暴露能力时用接口：比如
OrderService不直接暴露具体实现类，而是声明为OrderService接口类型，调用方只依赖行为，不感知是本地实现、RPC代理还是Mock桩 - 适配异构系统时靠接口：支付网关需对接微信、支付宝、银联，三者SDK结构完全不同，但可通过统一的
PaymentProcessor接口封装差异，新增渠道只需新增实现，不改调用逻辑 - 支持运行时插拔：Spring 的
BeanPostProcessor、ApplicationRunner都是接口，框架通过扫描所有实现类动态加载，这种扩展性依赖多实现能力，抽象类无法替代
抽象类是子系统内“骨架层”的载体
当多个组件属于同一业务域、共享数据模型与执行流程时，抽象类提供可复用的稳定骨架，把变化点留给子类定制。
- 模板方法模式落地：报表导出模块中，
AbstractReportExporter定义了validate() → fetch() → format() → save()流程，各子类只重写fetch()和format()，避免流程逻辑散落各处 - 共性状态与工具封装：微服务中通用的
BaseController抽象类可预置日志上下文、权限校验拦截器、统一响应包装逻辑，子控制器继承即得，无需重复注入或声明 - 版本兼容过渡：升级数据库访问层时，老代码仍调用
LegacyUserService，新代码用NewUserService，二者可共同继承AbstractUserService，复用缓存策略、异常转换等非核心逻辑
混合使用才能支撑复杂演进
真实架构里，二者极少单独存在，而是分层协作：
立即学习“Java免费学习笔记（深入）”；
- 顶层用接口定义能力契约（如
NotificationSender），确保上层模块不绑定实现 - 中层用抽象类提供通用实现（如
AbstractSmsSender封装签名、限流、重试），降低接入成本 - 底层用具体类完成差异化（如
AliyunSmsSender、TencentSmsSender只关注通道细节） - 当某类能力需跨域复用（如“幂等处理”），它会以接口形式被多个抽象类组合（
IdempotentHandler），而非继承，避免强耦合
关键判断信号帮你快速选型
遇到设计决策点时，问自己三个问题：
- 这个东西未来是否要被完全无关的类共用？→ 是，选接口
- 这些类是否共享字段、构造逻辑或默认行为？→ 是，考虑抽象类
- 是否需要在不修改调用方的前提下替换整套行为？→ 接口 + 依赖注入（如 Spring
@Qualifier）
不复杂但容易忽略
