接口定义“能做什么”（能力契约），抽象类定义“是什么”（类型归属）；接口支持正交能力组合与解耦，抽象类适合共享状态和流程复用；实际选型看能力是否跨域、有无共用状态/骨架、是否需多能力叠加。
面试时被问“接口与抽象类的核心区别”，别一上来就背语法条目。重点是让面试官听出你真写过业务代码、做过设计取舍。
先说清楚设计意图：不是“能不能”，而是“为什么”
接口回答的是“它能做什么”，是能力契约；抽象类回答的是“它是什么”，是类型归属。
- 比如一个订单对象，它是电商订单（
extends AbstractOrder），这是“是什么”——适合用抽象类 - 但它同时要能导出（
implements Exportable）、能审核（implements Approvable）、能发通知（implements Notifiable）——这些是正交能力，必须靠接口叠加
语法差异要服务于设计，不能孤立讲
Java 8+之后，接口也能有 default 方法，抽象类也能只写抽象方法。所以关键不在“有没有实现”，而在谁该管什么”：
- 接口里的 default 方法不能访问实例状态，只适合通用辅助逻辑（如
Collection.sort()） - 抽象类的具体方法可以操作 protected 字段、调用子类钩子、控制模板流程（如统一验签→调用→回调处理）
- 接口没有构造器、不能存可变状态，天然适合解耦；抽象类有构造器、能初始化共享字段，天然适合复用
选型就看三个实际问题
遇到新需求，快速判断用哪个，直接问自己：
立即学习“Java免费学习笔记（深入）”；
- 这个能力将来会不会被多个完全无关的类需要？比如“可重试”“可缓存”“可审计”——选接口
- 这几个类之间有没有共用的状态（如连接池、配置对象）或高度一致的执行骨架（如统一拦截、幂等处理）？——选抽象类
- 是否需要让一个类同时拥有多种正交能力？比如“既是支付渠道，又支持异步回调，还能生成对账单”——必须用接口组合，抽象类做不到
最后补一句落地经验
我之前在聚合支付项目里，把微信、支付宝都塞进一个抽象类，结果加云闪付时流程不兼容，硬加 if 判断导致代码越来越乱。后来拆成 PayChannel 抽象类管公共字段和基础方法，再用 AsyncCallbackCapable、Reconcilable 等接口按需叠加，扩展性立马变好。真实项目里，接口和抽象类经常是一起用的——接口定能力，抽象类做复用。
