接口定义跨域行为契约，抽象类构建领域内模板骨架；接口聚焦能力声明、粒度隔离，抽象类封装稳定流程、强制继承关系；二者协同实现松耦合与高复用。
在企业级 Java 应用中，接口与抽象类不是随意选用的语法选项，而是承载不同设计职责的架构构件。用错一个，轻则导致模块耦合变紧、扩展困难，重则让团队陷入“改一处崩一片”的维护泥潭。关键不在“能不能用”，而在“该不该在这里用”。
接口：定义跨域行为契约，不掺杂实现细节
接口在企业系统中应聚焦于“能力声明”，比如支付能力、通知能力、审计能力——这些能力常被多个无关领域复用，且实现来源可能完全不同（内部服务、第三方 SDK、Mock 测试桩）。
- 命名统一用动词短语或能力名词，如 PaymentProcessor、EventPublisher、IdempotentChecker，避免
IPayment或AbstractPayment这类冗余前缀 - 方法全部为
public abstract（可省略修饰符），禁止在接口中定义可变状态字段；所有字段自动视为public static final，仅用于声明配置常量（如MAX_RETRY_TIMES = 3） - 默认方法（
default）仅封装真正通用、无副作用的模板逻辑，例如统一日志埋点或空参校验；严禁在 default 方法中调用子类未约定的 protected 方法或访问非 final 字段 - 接口粒度遵循“角色隔离”原则：一个接口只表达一类能力。不要把
send()、retry()、encrypt()塞进同一个MessageService，而应拆为MessageSender、RetryPolicy、MessageEncryptor
抽象类：构建领域内可复用的模板骨架
抽象类适用于存在明确继承关系、共享大量基础结构的场景，比如订单处理链路中的 AbstractOrderProcessor、用户权限体系里的 AbstractPermissionValidator。它代表“是一类东西”，而非“能做某件事”。
- 类名必须以 Abstract 或 Base 开头，且为名词或名词短语，如 AbstractRefundPolicy、BaseTenantAwareService；禁止出现
AbstractBaseXXX等嵌套前缀 - 允许定义
protected构造方法，用于强制子类传递必要上下文（如租户 ID、业务类型）；普通方法只封装稳定不变的流程骨架（如“校验→预占→落库→发事件”），具体步骤由抽象方法留空 - 字段尽量设为
protected，或提供protected的 getter/setter；禁止public字段，避免子类直接篡改内部状态 - 抽象方法不得用
private、static、final修饰——这是编译强制约束，也是设计底线：抽象即意味着“留给子类决定”
协同使用：接口定义能力，抽象类实现骨架，具体类专注业务
典型分层模式是：接口暴露能力 → 抽象类提供默认实现路径 → 具体子类注入差异化逻辑。例如：
立即学习“Java免费学习笔记（深入）”；
- 定义
NotificationChannel接口，声明send(Notice)和supports(Type) - 提供
AbstractSmsChannel抽象类，封装签名拼接、频率限流、失败重试等通用逻辑，仅留doSend()为抽象方法 - 各业务线实现
MarketingSmsChannel、SecuritySmsChannel，只关心如何调用运营商 API，不重复写限流和重试
这种组合既保持了接口的松耦合优势，又通过抽象类降低了实现成本，还规避了单继承限制带来的僵化问题。
演进与治理：契约比代码更需管控
企业级项目中，接口和抽象类的变更直接影响下游所有实现方。因此必须纳入 API 治理流程：
- 接口新增方法需提供兼容性 default 实现，或走灰度发布+版本号升级（如
NotificationChannelV2） - 抽象类新增抽象方法属于破坏性变更，必须同步更新所有非 abstract 子类，并在 CI 中加入扫描规则（如 SonarQube 规则：禁止 abstract class 新增 abstract method 后未标记 @Incubating 或未更新子类）
- 所有对外暴露的接口/抽象类必须有 Javadoc 明确说明适用场景、线程安全模型、异常契约（哪些异常必须捕获，哪些可透传）
- 包路径体现层级意图：接口统一放在
api或contract包下（如com.example.payment.api），抽象类置于core或support（如com.example.payment.core）
