应根据设计意图选择：定义跨类型“能力”用接口默认方法，提供同族类“半成品流程”用抽象类抽象方法；前者支持多实现与向后兼容，后者支持状态共享与流程固化。
接口默认方法和抽象类抽象方法不是同一类东西，不能直接“对比选择”。它们出现在不同设计语境里：默认方法是接口的增强机制，用于向后兼容和能力组合；抽象方法是抽象类或接口中定义的、必须由子类/实现类补全的契约缺口。选谁，取决于你当前在解决什么问题。
看设计意图：你在定义“能力”还是在提供“半成品”
接口默认方法本质仍是为“能力契约”服务的——它让接口能在不破坏已有实现的前提下追加新行为。比如给 PayChannel 接口加一个 retryOnFailure() 默认方法，所有微信、支付宝实现类自动获得重试逻辑，无需修改代码。
抽象类中的抽象方法则服务于“流程固化”——它把共性骨架搭好（比如订单创建、验签、回调处理），只留出 doPayment() 这个抽象钩子让子类填空。这个方法不是可选能力，而是流程中不可跳过的环节。
简单说：
- 你想让多个不相关的类（比如 OrderService、RefundService、NotificationService）都具备“记录审计日志”的能力？用接口 + 默认方法
- 你想让微信、支付宝、银联这些支付渠道共享一套预校验+异步通知+对账的主干流程，只让它们各自实现签名细节？用抽象类 + 抽象方法
看继承结构：是否需要多实现或共享状态
默认方法天然支持多实现。一个类可以同时实现 Loggable、Retryable、Timeoutable 三个带默认方法的接口，轻松组合多种能力。
抽象方法若放在抽象类里，就绑定了单继承路径。一旦你继承了 BasePaymentService，就无法再继承别的基类——哪怕那个基类提供了你急需的加密工具或配置加载逻辑。
更关键的是状态。抽象类能持有 protected String merchantKey 这样的成员变量，子类直接复用；接口默认方法不能访问实例状态（没有 this），所有数据必须通过参数传入或从外部获取。
看演化需求：要不要保证老代码不崩
这是默认方法最不可替代的价值。假设你已上线 50 个支付渠道实现类，现在要统一支持“幂等重试”，只需在接口里加一个 default 方法：
public interface PayChannel {void pay(PayRequest req);
default boolean shouldRetryOn(Exception e) { return e instanceof NetworkException; }
}
所有老实现类立刻获得该能力，编译、运行零改动。而如果当初用的是抽象类，新增抽象方法会让所有子类编译失败——你得一个个去改，还可能漏掉某个外包团队维护的渠道。
别踩这两个典型坑
- 把默认方法当通用逻辑仓库：比如在 UserService 接口里塞一堆数据库操作的默认实现。这违反接口“定义能力”的本意，也容易因多实现导致方法冲突（两个接口都有同名 default 方法，子类必须重写明确选择）
- 用抽象类抽象方法代替接口定义顶层行为：比如定义 abstract class Payment，然后让所有支付方式继承它。这会锁死扩展——未来想让某个订单服务“支持支付能力”但又不想让它成为 Payment 的子类，就做不到了
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
