选接口还是抽象类，关键在于表达“能力”还是“身份”：接口定义横向可组合的能力（如Serializable），抽象类沉淀纵向类族的共性（如Animal）；二者常混合使用，接口定契约，抽象类做通用实现。
选接口还是抽象类，关键不在语法差异，而在你心里想表达的是“能力”还是“身份”。接口负责拓展行为，抽象类负责沉淀共性。用对了，代码既灵活又易维护；用混了，后期改起来处处是坑。
看类之间的关系：是“能做什么”，还是“属于什么”
如果多个类天然属于同一类事物，有共同状态和基础逻辑，优先考虑抽象类。比如 Animal、Vehicle、Shape，它们不是临时拼凑的能力，而是有明确的语义归属。
- 它们共享字段（如 name、color、id）
- 需要统一初始化（靠构造方法完成）
- 有大量可复用的具体行为（如 sleep()、startEngine()、showColor()）
反之，如果只是临时赋予某类对象一项额外能力，比如“能序列化”“能比较大小”“能被监控”，那就用接口。一个 Order 类可以同时实现 Serializable、Comparable
看复用需求：要不要共享状态或初始化逻辑
抽象类能带状态、带构造器、带 protected 方法，适合封装子类真正共用的底层细节。比如所有数据库访问类都需要连接池、重试策略、日志上下文——这些可以直接写在抽象基类里，子类拿过去就能用。
立即学习“Java免费学习笔记（深入）”；
- 需要初始化字段？→ 抽象类（有构造方法）
- 需要子类共用某个 private 工具方法？→ 抽象类（支持 private 成员）
- 需要定义包级可见的字段或方法？→ 抽象类（接口只能 public）
接口没有实例状态，所有字段默认 public static final，无法保存运行时数据。它的复用靠 default 方法提供通用逻辑，但这些方法不能访问 this 状态，适用场景有限（比如通用校验、空值处理、简单转换）。
看扩展路径：未来会不会需要多维度组合
业务演进中，一个类常需叠加多种职责。比如一个支付服务既要支持异步回调（AsyncCallbackHandler），又要接入风控系统（RiskCheckable），还要可灰度发布（CanaryEnabled）。这种横向能力叠加，只有接口能自然支撑。
- 一个类只能继承一个抽象类 → 绑死纵向继承链
- 一个类可实现任意多个接口 → 横向能力自由装配
- 接口还能继承其他接口（如 List extends Collection），形成能力层级
如果你预判这个抽象将来会被不同体系的类复用（比如 Web 层和 Job 层都要用某种规则引擎），那接口更稳妥；如果它只服务于一个明确的类族（如所有报表导出器：ExcelExport、PdfExport、CsvExport），抽象类更直接。
混合使用才是常态：接口定义能力，抽象类落地实现
大型项目里，二者往往配合使用。典型模式是：先定义接口划清契约，再提供抽象类降低接入成本。
- 定义 PaymentProcessor 接口：声明 process()、refund()、queryStatus()
- 提供 AbstractPaymentProcessor 抽象类：封装幂等校验、日志埋点、异常统一转换
- 具体支付渠道（AlipayProcessor、WechatProcessor）继承抽象类，专注实现核心差异逻辑
这样既保留了接口的灵活性（后续可让非 Java 系统通过 RPC 实现同一接口），又通过抽象类避免每个实现都重复写模板代码。复用性和扩展性都不牺牲。
