接口回答“它能干什么”，抽象类回答“它是什么”；二者是能力声明与骨架复用的协作关系，非替代关系。
别背“接口用 implements、抽象类用 extends”这种表面规则——这是混淆的起点。真正要避开陷阱，得从设计意图切入：接口回答“它能干什么”，抽象类回答“它是什么”。两者不是替代关系，而是协作关系。
陷阱一：把语法差异当设计依据
很多人一上来就列对比表：接口不能有构造器、字段只能是 public static final、抽象类可以有普通方法……这些没错，但全是结果，不是原因。比如“接口不能有构造器”，本质是因为接口不描述实例化对象，它只是一份能力契约；而抽象类虽不能 new，但子类构造时必须调用它的构造器，因为它承载初始化逻辑和共享状态。
- 看到“接口字段默认 public static final”，想一想：契约里哪需要可变状态？常量才保证行为一致
- 看到“抽象类可含普通方法”，问一句：这段逻辑是不是所有子类都该复用？还是只是临时凑数？
- JDK 8 后接口有了 default 方法，不等于它变成抽象类——default 方法只能访问自身常量或参数，无法访问实现类的 this 状态
陷阱二：用继承关系代替能力组合
写一个 User 类，发现它既要能登录（Loginable）、又要能导出数据（Exportable）、还要支持审计日志（Auditable）。这时候如果建 LoginableAbstract、ExportableAbstract、AuditableAbstract 三个抽象类，再让 User 去继承其中一个——立刻掉坑里了。Java 不支持多继承，但支持多实现。
- 登录、导出、审计是三种独立能力，彼此无血缘关系 → 全部定义为接口
- 如果多个用户类型（AdminUser、GuestUser、RobotUser）共用同一套 token 校验逻辑和 session 管理字段 → 抽象类适合封装这部分
- 正确姿势：User implements Loginable, Exportable, Auditable；必要时继承 BaseUserAbstract（含通用 token 解析、session 初始化等）
陷阱三：在抽象类里塞进无关职责
曾见一个叫 “BaseService” 的抽象类，里面混着数据库连接初始化、HTTP 客户端构建、日志打印模板、甚至加解密工具方法。这不是抽象类，这是“工具方法大杂烩”。抽象类的核心价值是提供可继承的骨架，不是当静态工具箱用。
- 判断标准：这个方法是否天然属于“子类的共同行为”？比如所有支付渠道都要验签，那 verifySignature() 放抽象类合理；但所有服务都要打日志，log.info() 就不该放进去，应由 AOP 或统一日志框架处理
- 字段同理：name、code、createdAt 这类业务实体共有属性可放抽象类；但 connection、httpClient、redisTemplate 这些是资源依赖，应通过构造注入或 Spring @Autowired，而非继承获得
- 一旦抽象类开始承担“非领域共性”职责，它就从骨架退化成耦合源
陷阱四：忽略“声明类型”背后的契约意义
面试官问：“List list = new ArrayList(); 和 ArrayList list = new ArrayList(); 有什么区别？”答“前者多态”太浅。关键在于：左边声明的是你向调用方承诺的能力边界。
- 声明为 List → 你只承诺支持增删查改、按索引访问；调用方不依赖扩容机制、不依赖数组结构；未来可无缝换成 LinkedList 或 CopyOnWriteArrayList
- 声明为 ArrayList → 你把底层实现细节暴露出去了；调用方可能写出 list.ensureCapacity(1000)，一旦换实现就编译报错
- 同理：方法参数用 UserService 接口，而不是 UserServiceImpl；返回值用 Readable 接口，而不是 FileReader 实例 —— 这才是接口存在的真实价值
不复杂但容易忽略：接口与抽象类不是非此即彼的选择题，而是“能力声明”与“骨架复用”的分工。先问自己两个问题：我要约束的是“一类东西的共同本质”，还是“一组东西的共同能力”？我要复用的是“代码逻辑”，还是“行为契约”？答案清晰了，选型自然就稳了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
