该用 abstract class 而非 interface 的情况是：需共享实例状态（如 retrycount）、复用具体逻辑、构建“is-a”继承体系；abstract class 支持 protected/private 成员、带参构造、初始化复用，而 interface 无法持有状态且 default 方法能力受限、易引发歧义与维护风险。
什么时候该用 abstract class，而不是 interface
当你需要共享状态（比如实例变量）、复用具体逻辑、或构建明确的“is-a”继承体系时，abstract class 是更自然的选择。比如多个支付渠道（AlipayPayment、WechatPayment）都共用同一套订单校验逻辑和 retryCount 计数器，这时抽象父类能直接封装这些。
常见错误是：为图“看起来解耦”，硬把本该有共同字段和初始化流程的类塞进接口——结果每个实现类都要重复写 private int timeout = 5000; 和构造时赋值逻辑，反而增加维护成本。
- 抽象类可定义
protected字段、private工具方法、带参数的构造函数，子类通过super()复用初始化流程 - 接口无法持有实例状态，所有字段自动变成
public static final，改个默认超时值就得全量编译所有实现类 - 若未来要加一个非抽象方法（比如统一日志打点），在抽象类中直接加即可；在接口里加
default方法看似方便，但旧实现可能因忽略该方法行为而产生隐性不一致
Java 8+ 的 default 方法真能替代抽象类吗
不能。它只是补救机制，不是设计替代品。接口加 default 方法的初衷是：在不破坏已有实现的前提下，给集合类等广泛使用的接口追加新能力（如 Collection.removeIf()）。
但滥用 default 会模糊接口的契约本质——它本该只回答“能做什么”，不该掺杂“怎么去做”。一旦你在接口里写了一堆带 this. 引用、调用其他 default 方法、甚至抛异常的逻辑，那它已经不是接口，而是披着接口外衣的抽象类。
立即学习“Java免费学习笔记（深入）”；
-
default方法不能访问实现类的实例变量，只能操作参数或调用其他接口方法，能力受限 - 若两个接口提供了同签名的
default方法，实现类必须显式重写，否则编译报错：classes A and B both define method X(), which is inherited from interface - 测试难度上升：你得 mock 掉整个接口来验证
default行为，而抽象类的方法天然可被子类单元测试覆盖
为什么一个类能 implements 多个接口，却只能 extends 一个抽象类
这是 Java 单继承模型的硬性约束，根源在于字段冲突和构造链歧义。如果允许多继承，当两个父类都有 protected String id;，子类该用谁的？构造时先调谁的 super()？JVM 没法自动决策。
而接口没有实例字段、没有构造过程、所有方法默认 public，多个接口的抽象方法合并后，只要签名不冲突，实现类一次性覆盖即可——这是安全的、无歧义的组合。
- 典型场景：
OrderService同时implements Payable、Loggable、Retryable，每个接口只声明一个关注点，互不干扰 - 若强行用抽象类模拟多继承，比如让
PayableAbstract和LoggableAbstract都继承自BaseService，那业务类就只能选其一，失去正交性 - 注意：抽象类可以
implements接口，所以常见模式是“抽象类 + 多接口”混合使用，既复用代码，又扩展能力
选错类型会导致哪些真实上线问题
最隐蔽的问题不是编译失败，而是运行时行为漂移和升级踩坑。比如把本该是抽象类的基类改成接口后加了 default 方法，某些子模块没重新编译，仍链接旧版 jar——表面正常，但新 default 逻辑完全没执行。
另一个高频问题是序列化：抽象类里的 transient 字段、自定义 writeObject() 可控；而接口连字段都没有，一旦需要持久化上下文状态，只能推倒重来。
- Android 开发中，抽象类可被
@Keep保留，ProGuard 不会误删其方法；接口的default方法在混淆后可能因未被显式引用而被裁剪，导致NoSuchMethodError - Spring AOP 对抽象类方法代理稳定；对接口的
default方法代理支持有限，部分版本会跳过增强 - 团队协作中，新人看到接口里一堆
default实现，容易误以为“不用管，反正有默认”，结果绕过关键校验逻辑
抽象类和接口的边界，在于你是否需要“携带状态”和“控制初始化过程”。这点一旦模糊，后续每加一个功能，都会多一层理解成本。
