接口是契约，抽象类是半成品类；定义能力选接口，封装状态和复用逻辑选抽象类。
接口和抽象类根本不是同一类设计工具——接口是“契约”，抽象类是“半成品类”。选错会导致后续扩展困难、代码复用失效，甚至引发编译错误。
什么时候该用 interface 而不是 abstract class
当你需要定义“能力”而非“身份”，且这个能力可能横跨完全无关的类体系时，必须用接口。
- 比如
Runnable、Comparable、Serializable：Thread和TimerTask毫无继承关系，但都能run()；String和LocalDateTime也不相关，但都可compareTo() - 一个类要同时具备多种行为（如既能飞又能叫还能存储），只能靠
implements A, B, C；用抽象类就卡死在单继承里 - 接口支持默认方法（
default）后，可以安全地向已有接口添加新方法，不破坏实现类——抽象类加新抽象方法会强制所有子类改代码
为什么 abstract class 不能替代 interface 做多继承
Java 类只能 extends 一个父类，这是语言硬限制。哪怕你把抽象类写得再“轻量”，也无法绕过它。
- 错误尝试：
class Duck extends Bird implements Flyable✅ 可行；但class Duck extends Bird extends Actionable❌ 编译报错：error: duplicate superinterface Actionable - 抽象类可以有
protected成员变量、构造器、初始化块——这些在接口里全被禁止（接口没有状态，也没有实例化过程） - 如果你发现多个实现类反复复制同一段逻辑（比如日志、校验、缓存），那抽象类才是解药；接口只管“有没有这个方法”，不管“怎么实现”
default 方法和 abstract 方法混用时的常见陷阱
JDK 8+ 允许接口含 default 方法，但容易误以为它能替代抽象类的模板能力——其实不能。
-
default方法无法访问实现类的私有字段或this引用的非公开状态，而抽象类的普通方法可以 - 接口中两个
default方法若同名且签名一致，实现类必须显式重写，否则编译失败；抽象类不存在这种“冲突需手动解决”的问题 - 别在接口里写复杂逻辑：默认方法适合简单委托（如
Collections.emptyList()）、空实现（如MouseListener.mouseClicked()），而不是业务骨架
构造器、成员变量和访问控制的实际影响
这是最常被忽略的底层差异，直接决定你能否封装状态、控制可见性、做安全初始化。
- 抽象类可以有
protected String name和public Animal(String name)构造器；接口连private或protected关键字都不允许出现 - 接口中所有变量自动是
public static final，哪怕你写int MAX = 100，实际等价于public static final int MAX = 100；而抽象类里的private int count就是真的私有字段 - 抽象类能用
final修饰具体方法防止子类覆盖；接口方法永远不能加final（语法错误
），因为它的本质就是“可被任意实现”
interface Flyable {
int MAX_HEIGHT = 10000; // 自动 public static final
void fly(); // 自动 public abstract
default void land() {
System.out.println("Landing safely");
// ❌ 不能访问 this.name 或 private 字段
}
}
abstract class Bird {
protected String name;
private int wingSpan;
public Bird(String name, int wingSpan) { // ✅ 有构造器
this.name = name;
this.wingSpan = wingSpan;
}
public abstract void chirp();
public void rest() { // ✅ 可以访问 this.name
System.out.println(name + " is resting");
}
}
真正难的不是记住语法区别，而是判断“这个共性到底属于‘是什么’还是‘能做什么’”——前者归抽象类，后者归接口。一旦混淆，后期加字段、改行为、引入新模块时，重构成本会指数级上升。
