可扩展的继承需明确“为什么继承”和“怎么继承”，用抽象类定义稳定骨架、抽象方法封装变化点，遵守里氏替换原则，优先接口组合与钩子机制，确保变与不变分离。
Java 中继承关系的设计，关键不在“能不能继承”，而在于“为什么继承”和“怎么继承才不卡死后续演进”。真正可扩展的继承，是让新功能能自然插进来，老代码几乎不用动。
用抽象类定义稳定骨架，把变化点留给子类实现
父类负责流程控制和通用逻辑，子类只专注自己独有的行为。比如报表生成器中，父类写好 generateReport() 主干流程，再声明 fetchData() 和 formatData() 为抽象方法——数据从哪来、格式怎么变，全由子类决定。这样加一种新报表类型，只需新增一个子类，完全不影响原有逻辑。
- 避免在父类里写具体业务判断（如 if (type == "pdf") {...}）
- 抽象方法命名要体现职责，而不是技术细节（比如用
render()而不是toHtmlString()） - 构造逻辑尽量推迟到子类，父类只做必要初始化（如设置基础状态、校验非空）
严格遵守里氏替换原则（LSP），子类必须是父类的合理特化
子类不能破坏父类的行为契约。如果父类方法假设“金额总是正数”，子类就不能在重写时悄悄把它设为零；如果父类允许 null 输入，子类也不能突然抛 NPE。否则调用方一升级就出错，扩展反而成了破环。
- 子类不新增与父类语义冲突的状态字段（比如父类用
status表示运行态，子类再加个stateFlag就容易混乱） - 重写方法时，输入范围不缩窄、输出范围不扩宽（参数类型不能更严格，返回类型不能更宽泛）
- 用单元测试覆盖父类契约，每次新增子类都跑一遍，确保它真能“替代”父类
优先用接口组合，慎用深层继承链
Java 只支持单继承，但接口可以多重继承。与其拉长 “A → B → C → D” 四层继承，不如让类实现多个清晰职责的接口：比如 Runnable、Loggable、Configurable。这样功能可插拔，也方便后期拆分或替换。
- 接口之间可用
extends组合（如AdvancedFlyable extends Flyable, Maneuverable），表达能力叠加 - 类内部优先通过字段持有其他行为对象（组合），而不是靠继承获得全部能力
- 超过三层的继承链，建议审视是否该重构为策略模式或模板方法+委托
预留扩展钩子，但不提前实现
在父类关键节点留空方法（如 beforeSave()、onError()），默认空实现。子类按需覆写，不需要的就忽略。这样既不强制子类处理，又为未来埋下入口，比后期加抽象方法或改签名更安全。
- 钩子方法用
protected修饰，避免外部误调 - 在 JavaDoc 明确说明用途和调用时机（例如：“在保存前执行，可用于数据预处理”）
- 避免在钩子里做强依赖或耗时操作，保持主流程轻量
不复杂但容易忽略：可扩展的继承，本质是把“变”和“不变”切得干净，再用语言机制守住边界。接口划清能力契约，抽象类稳住流程骨架，子类只填空白——系统自然就能边长边跑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
