验证继承是否符合里氏替换原则（LSP）最本质的方式是检查“换而不变”：父类实例替换为子类实例后，返回值、异常、副作用和执行逻辑必须完全一致；需自问三关键问题并严查方法重写的四大雷区；发现违规时优先采用接口、组合或抽象基类替代继承。
直接看行为是否“换而不变”：把父类实例替换成子类实例，不改任何调用代码，结果（返回值、异常、副作用、执行逻辑）必须完全一致。这是验证继承关系是否符合里氏替换原则（lsp）最本质、最可靠的方式。
用三句关键问题现场拷问
每次写完子类或重构继承结构时，快速自问：
- 有没有地方把 父类变量声明 换成子类对象后，程序输出变了、抛了新异常、或界面/流程出错？
- 子类是否重写了父类的非 abstract 方法？如果重写了，它是否一字不差地遵守原方法的契约——包括参数范围、返回含义、文档承诺、副作用（比如是否修改状态）、甚至注释里写的特殊规则？
- 子类新增的方法，会不会诱使别人写出
if (obj instanceof SubClass) { ((SubClass)obj).specialMethod(); }这样的代码？一旦出现，说明这个继承关系本就不该存在。
重点盯住方法重写的四大雷区
子类重写父类已实现方法，是 LSP 最常见的断裂点。务必检查以下四点是否被破坏：
-
前置条件不能收紧：父类方法接受
int amount（允许任意整数），子类就不能只接受正偶数；但可以放宽（比如接受Number）。 - 后置条件不能削弱：父类承诺“返回非负 BigDecimal”，子类就不能返回可能为负的值；但可以加强（比如保证返回 ≥ 100）。
-
异常类型不能新增：父类方法签名没声明异常，子类就不能在运行时抛出
InsufficientCreditException；若必须处理新情况，应统一在父类中声明基类异常。 -
副作用不能偷换：父类
withdraw()只扣款，子类就不能悄悄冻结账户或发短信——这些属于新增行为，应通过新方法暴露，而非覆盖原有语义。
用工具+测试做实证验证
别靠感觉，用工程手段落地：
- 在 IDE 中对父类做 Find Usages，找出所有直接使用父类类型声明和调用的地方。
- 逐个把
Parent p = new Parent();替换成Parent p = new Child();，运行原有单元测试——只要一个测试失败，就说明 LSP 被破坏。 - 对关键方法（如
toString()、equals()、save()）单独补契约测试：输入相同参数，断言返回值类型、内容、是否抛异常，与父类行为严格对齐。
当发现不合适时，优先考虑替代方案
一旦确认继承关系踩了 LSP 红线，不要硬修重写逻辑。更健壮的设计通常是：
-
退到接口：让 Rectangle 和 Square 都实现
Shape接口，各自独立实现getArea()和resize()，不共享可变状态。 - 改用组合：Square 内部持有一个 Rectangle 实例，需要面积时委托调用，需要“宽高同步”逻辑则封装在自身方法里，不污染父类契约。
-
提取抽象基类：若多个子类共用部分行为，可新建一个 abstract 类（如
ResizableShape），把可安全继承的行为放进去，而把易变逻辑留在具体子类中实现。
