应优先用接口声明行为契约，仅当存在“is-a”关系且需复用具体实现时才用继承；密封类可安全管控继承范围，组合则用于“has-a”关系。
什么时候该用继承而不是接口
当子类和父类之间存在明确的“is-a”关系，且需要复用具体实现（比如字段、非抽象方法、构造逻辑）时，继承更合适。Java 中 extends 只能单继承，所以这个选择会锁死类的上层结构。
常见错误是为了一点共用代码强行设计父类，结果导致后续扩展困难——比如把 Animal 设计成具体类，再让 Dog 和 RobotDog 都去继承它，后者根本不是生物，却被迫套进同一套生命周期方法里。
- 适合继承的场景：
ArrayList继承AbstractList（复用迭代器、size()等通用逻辑） - 避免继承的信号：父类里出现大量
throw new UnsupportedOperationException()方法 - 若只共享行为契约、不共享状态或实现，优先考虑接口
接口中 default 方法不是“多继承”的捷径
default 方法确实允许接口提供实现，但它不能访问实例字段，也不能调用 super 调用父接口的同名方法（Java 不支持接口继承链上的 super 调用）。它本质是契约的“可选实现”，不是真正的复用机制。
滥用 default 会导致接口职责膨胀，比如在 Comparable 里加 default sort()，这就越界了——排序是集合行为，不该由单个可比较对象承担。
立即学习“Java免费学习笔记（深入）”；
- 合理用法：
Collection接口的stream()、parallelStream() - 危险信号：一个接口里有超过 2 个
default方法，且它们相互调用 - 注意冲突：如果类同时实现两个含同名
default方法的接口，必须显式重写该方法，否则编译报错class inherits unrelated defaults for method
组合优于继承，但接口不是组合的替代品
组合解决的是“has-a”或“uses-a”关系，比如 Car 持有 Engine 实例；而接口解决的是“can-do”能力声明，比如 Car implements Drivable, Insurable。两者定位不同，常一起使用。
典型误用是用接口模拟状态继承：定义 HasName 接口并配上 getName() 和 setName(String)，再让几十个类都实现它——这其实是在重复定义字段，应该用抽象基类或组合一个 NameableComponent。
- 接口应聚焦行为契约，而非数据结构：用
Readable而不是HasBuffer - 组合对象可实现多个接口，天然支持能力叠加，比如
FileReader implements Readable, Closeable - 若组合对象本身需被统一处理（如所有“可关闭资源”），仍要靠接口统一类型，而不是靠继承强制归类
Java 17+ 密封类（sealed classes）正在改变继承设计权衡
当继承不可避免，又想限制子类范围（比如只允许 Circle、Rect、Triangle 扩展 Shape），sealed 类比开放继承 + 文档约束更可靠。它让继承关系变成显式白名单，配合 permits 关键字，在编译期就防止非法子类。
这时候接口反而退居二线：你不再需要靠 Shape 接口来统一多态入口，因为 sealed class Shape 本身已具备类型安全的多态能力；接口更适合补充额外能力，比如 Shape extends Serializable, Comparable<Shape>。
- 密封类不能和
final或non-sealed同时修饰，语法错误会直接报illegal combination of modifiers - 子类必须显式用
extends或implements声明，并出现在permits列表中 - 如果未来要新增子类，必须修改父类源码（这是设计意图，不是缺陷）
public sealed abstract class Shape
permits Circle, Rect, Triangle {
public abstract double area();
}
继承与接口不是二选一的选择题，而是分层协作工具：接口划清能力边界，继承（尤其是密封继承）管理结构演化，组合落实具体职责。最容易被忽略的是——把接口当成“轻量级继承”来用，结果让接口承担了本该由类层次或组件模型解决的问题。
