继承仅适用于满足“is-a”关系的类，如Dog是Animal；应避免“has-a”关系（如Car与Engine）而改用组合；父类需可扩展、稳定；多层继承不宜超过三层；优先使用接口、组合和设计模式。
当子类确实是父类的一种特殊类型，且需要复用父类的属性和方法时，才适合使用继承。
满足“is-a”关系是前提
继承表达的是“是一个”的语义。比如Student是Person的一种，Circle是Shape的一种。如果只是“有一个”或“用到”，比如Car有Engine，就不该让Car继承Engine，而应使用组合（成员变量引用）。
- ✅ 正确：class Dog extends Animal —— 狗是一种动物
- ❌ 错误：class Car extends Engine —— 汽车不是一个引擎
父类需具备可扩展性和稳定性
被继承的类应当设计为支持继承：方法尽量用protected而非private，关键行为可被重写（非final），并提供清晰的文档说明哪些方法可以/应该被覆盖。若父类频繁修改内部逻辑、大量使用private字段或未预留钩子，强行继承容易导致子类脆弱、难以维护。
- 避免继承工具类（如StringUtils）、配置类或高度封装的业务实体
- 优先选择抽象类或接口定义契约，再由具体类实现或继承
多层继承要谨慎，深度建议不超过三层
过深的继承链（如A→B→C→D）会显著增加理解成本和修改风险：某处改动可能引发远端子类行为异常，调试困难，且违背开闭原则。Java不支持多重继承，也限制了灵活性。
立即学习“Java免费学习笔记（深入）”；
- 两层继承（基类→子类）最常见、最可控
- 三层仅在领域模型明确分层时考虑（如Animal → Mammal → Dog）
- 超过三层，优先拆分为组合+接口实现
替代方案往往更合适
多数场景下，组合（has-a）、委托、接口实现比继承更灵活、低耦合。尤其当目标是代码复用或行为扩展时，优先考虑：
- 用接口定义能力（如Runnable、Comparable）
- 用组合持有对象，通过方法调用复用逻辑
- 用策略模式、模板方法等设计模式解耦变化点
继承不是代码复用的首选，而是建模“本质分类关系”的手段。
