接口与抽象类有什么区别，真实业务中如何选择？

核心回答

接口适合定义可替换的能力约定，抽象类适合为一组相关实现提供共同的状态、约束和实现骨架。 选择时不能只背“单继承、多实现”，也不能再把接口理解成“只能声明没有方法体的方法”。

以现代 Java（这里按 Java SE 25 规则）比较：

• 类型关系：类只能直接继承一个类，但可以实现多个接口；接口也可以继承多个接口。接口便于让不同继承体系中的类遵守同一约定，抽象类则占用了实现类的父类位置。
• 状态和构造：抽象类可以有实例字段、构造器和不同可见性的成员，用于初始化和维护公共状态。接口没有实例字段或构造器，字段隐含为 public static final，不能用来保存每个对象独立的可变状态；final 引用也不等于其指向的对象不可变。
• 方法实现：抽象类可以同时有抽象方法和具体方法。Java 8 起，接口可以有 default、static 方法；Java 9 起，可以有 private 方法，在接口内部复用实现。接口并非完全不能复用代码。
• 实例化：两者都不能直接实例化，但都可以作为变量、参数和返回值类型。抽象类不要求一定含有抽象方法，具体子类则必须补齐尚未实现的抽象方法。

真实业务中怎么选择？

以接入多个支付渠道为参考例子，调用方需要的是发起支付、查询结果等能力，而不是依赖某个渠道的实现细节。可以先定义 PaymentGateway 接口，让不同渠道分别实现，调用方通过这个约定使用它们。这样实现类仍能继承自己需要的其他父类，也方便替换实现和测试替身。

如果其中几种实现确实共享稳定的状态与流程，例如都要依次完成参数校验、请求构造、发送、响应转换，而且流程约束相同，可以再提供实现该接口的抽象基类：保存公共依赖或配置，实现公共步骤，让子类补充渠道差异。必要时把不允许改变的流程入口定义为 final，保留明确的扩展点。

因此，接口和抽象类可以同时使用：调用方依赖接口，部分实现选择复用抽象基类，其他实现直接实现接口。

也不要为了减少几行重复代码就建立继承关系。若公共部分只是日志、签名或序列化等独立能力，可以把它们做成被组合的协作对象。否则基类很容易堆满条件分支，某个子类每次都要绕过或覆盖公共行为，反而增加修改成本。

有 default 方法，为什么还需要抽象类？

default 适合基于接口已有能力提供一个合理的默认行为；接口的 private 方法可帮助这些默认行为复用内部代码。但接口不能像抽象类那样，通过构造器建立每个实例的状态和约束，也不能提供 protected 实例扩展点。

此外，接口声明的 static 方法不由实现类继承为实例行为，private 方法也不会成为实现类可覆盖的扩展点。它们不能直接替代抽象类中的状态和继承结构。

给现有接口增加 default 方法，也不代表一定没有兼容问题。如果多个无明确优先关系的接口提供了冲突的默认实现，子类型需要显式解决冲突；默认行为是否符合每个实现的业务语义，也要单独判断。

面试中怎么把取舍讲具体？

可以回答三个问题：调用方需要稳定的什么能力；实现之间是否确实存在共同状态和流程；这些共同部分是否稳定到值得用继承绑定。

如果主要是隔离不同实现，接口通常更合适；如果相关实现需要共享受约束的状态和流程，抽象类有价值；如果只是复用独立工具能力，组合通常更灵活。设计不要求每个类都配一个接口或抽象父类，应由实际变化点决定。

参考资料