接口定义行为契约、抽象类封装共用逻辑，二者协同分工：接口聚焦“能做什么”，抽象类解决“怎么做一部分”，典型模式如list接口与abstractlist抽象类。
Java 中接口与抽象类协同定义统一行为标准，关键不在于“二选一”，而在于分工配合：接口负责划清能力边界，抽象类负责沉淀共用逻辑。
接口定义清晰的行为契约
接口聚焦“能做什么”，用方法签名声明一类对象必须支持的操作，不关心具体实现。所有实现类都遵守同一套调用方式，调用方只需面向接口编程，无需知道背后是哪个类。
- 方法默认为 public abstract，强制实现类提供具体行为
- 可定义 default 方法提供可选的通用实现（如
Collection.forEach()） - 可定义 static 方法封装工具逻辑（如
Comparator.naturalOrder()） - 一个类能 implements 多个接口，轻松组合多种能力（如
Runnable & Serializable & Cloneable）
抽象类封装可复用的骨架实现
抽象类解决“怎么做一部分”，把流程控制、公共字段、基础校验、默认行为等收拢到父类中，子类只专注差异化部分。
- 提供 模板方法模式：用
final方法定义固定流程（如process()），留出抽象钩子（如transform()）让子类填充 - 允许定义 protected 成员变量和构造器，支持状态共享与初始化（如
AbstractList中的modCount） - 可包含普通方法实现，避免子类重复写日志、空值检查、资源关闭等通用逻辑
- 子类继承后，天然获得结构一致性，也便于统一增强（如统一加监控、统一打日志）
组合使用：先接口，再抽象骨架
这是 JDK 和主流框架常用的设计范式——先用接口确立规范，再用抽象类降低实现门槛。
- 对外暴露的是接口（如
List<e></e>），保证 API 稳定性和多态扩展性 - 提供配套抽象类（如
AbstractList<e></e>），实现iterator()、size()等通用逻辑 - 开发者可自由选择：直接实现接口（完全定制），或 继承抽象类（只重写必要方法）
- 类似模式还有
Servlet接口 +HttpServlet抽象类、ChannelHandler+SimpleChannelInboundHandler
选型判断看这三点
遇到设计决策时，快速对照业务需求：
- 需要描述“具备某种能力”（比如可导出、可序列化、可比较）→ 优先定义 接口
- 多个子类有相同字段、相似流程、重复代码 → 适合提取 抽象类
- 既要统一行为契约，又要减少实现成本 → 接口 + 抽象骨架类 是最佳实践
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
