接口适合定义行为契约，如序列化、比较；抽象类适合共享状态与部分实现，如Animal；Java单继承限制使接口成为多重继承唯一选择；default方法冲突需显式解决，演化成本需谨慎评估。
接口更适合定义能力契约
当你要表达“能做什么”，而不是“是谁”，就该用 interface。比如多个不相关的类都需要支持序列化、比较、监听，这些是行为契约，和继承关系无关。
public interface Serializable {
byte[] serialize();
void deserialize(byte[] data);
}Java 8+ 允许 default 方法提供默认实现，但本质仍是契约——子类可覆盖、可忽略，不强制继承实现逻辑。注意：接口不能有构造器、不能有非 public static final 字段、不能有实例变量。如果你在接口里加了 private 方法（Java 9+ 支持），那也只是为了复用 default 方法逻辑，不是为了封装状态。
抽象类更适合共享状态与部分实现
当你有一组类有共同字段、构造逻辑、模板方法，且天然存在“is-a”关系时，abstract class 更合适。比如 Animal 抽象类可以持有 name、age，定义 live() 模板方法，并强制子类实现 makeSound()：
public abstract class Animal {
protected String name;
protected int age;
<pre class='brush:java;toolbar:false;'>public Animal(String name, int age) {
this.name = name;
this.age = age;
}
public final void live() {
breathe();
eat();
makeSound(); // 子类必须实现
}
protected abstract void makeSound();
}关键区别：抽象类支持构造器、成员变量、protected / private 方法、静态代码块；一个类只能继承一个抽象类，但能实现多个接口。
遇到多重继承需求时，接口是唯一选择
Java 不支持多继承类，但允许一个类 implements 多个接口。比如一个类既要可排序（Comparable），又要可关闭（AutoCloseable），还要可序列化（自定义 Serializable 接口），只能靠接口组合：
public class DataProcessor implements Comparable<DataProcessor>, AutoCloseable, Serializable {
@Override
public int compareTo(DataProcessor o) { /* ... */ }
@Override
public void close() { /* ... */ }
@Override
public byte[] serialize() { /* ... */ }
}如果强行用抽象类模拟，会立刻撞上单继承限制。更隐蔽的坑是：有人把抽象类设计成“工具集”，塞一堆 static 工具方法，这其实违背抽象类语义——这种场景该用普通工具类（final + 私有构造器）或接口（Java 8+ static 方法）。
默认方法冲突时，编译器强制你解决
当一个类同时实现两个接口，而这两个接口都提供了同签名的 default 方法，Java 编译器会报错：class X inherits unrelated defaults for method Y from types A and B。你必须在类中显式重写该方法，哪怕只是调用其中一个：
public class X implements A, B {
@Override
public void doWork() {
A.super.doWork(); // 或 B.super.doWork()
}
}这不是缺陷，而是设计约束：避免隐式行为歧义。相比之下，抽象类的继承链中方法优先级明确（子类 > 父类 > 祖父类），没有这类冲突问题。但这也意味着，接口的 default 方法不能随意添加——它可能破坏下游实现类的编译。
真正容易被忽略的是演化成本：一旦发布公开接口并被第三方实现，加新 default 方法相对安全；但加新抽象方法则必然导致所有实现类编译失败。反过来，抽象类新增非抽象方法影响较小，但修改已有抽象方法签名或移除字段，同样会破坏二进制兼容性。选型时，得先想清楚这个类型未来三年会不会变、谁会用它、谁负责维护它。
