里氏替换原则要求子类在父类出现的任何地方行为不破坏原有逻辑，而非仅编译通过；常见违反包括扩大异常、削弱前置条件、加强后置条件，应通过契约测试、模板方法或组合等方式保障。
为什么子类重写方法后，父类引用调用出错了
里氏替换原则不是“只要能编译通过就行”，而是要求子类对象在任何父类出现的地方，行为不破坏原有逻辑。常见错误是：子类重写了 calculateDiscount()，但把原本返回正数的逻辑改成可能返回负数，而下游代码直接用结果做减法，导致价格变正数反而涨价。
- 典型现象：
ClassCastException不会出现，但运行时数值错乱、空指针、状态不一致——这类问题往往测试覆盖不到父类上下文 - 关键判断点：看父类方法的契约（文档、注释、已有单元测试），不是看签名是否匹配
- 如果父类
save()方法保证“成功即持久化”，子类就不能改成只写缓存、延迟落库，除非父类契约本身就允许
用 @Override 修饰但依然违反 LSP 的三种情况
Java 编译器只检查签名，不校验语义。以下操作语法合法，却实质破坏 LSP：
- 扩大异常范围：父类
parseJson()声明抛IllegalArgumentException，子类重写后抛IOException—— 调用方没准备捕获后者 - 削弱前置条件：父类要求
id != null，子类实现里允许id == null并返回默认值，看似友好，但可能掩盖上游传参错误 - 加强后置条件：父类
getItems()返回可修改的List，子类返回Collections.unmodifiableList()—— 调用方原逻辑是先add()再处理，现在直接UnsupportedOperationException
如何让子类安全地“增强”父类功能
增强 ≠ 改变契约。真正符合 LSP 的增强，是在父类定义的边界内做扩展：
- 用模板方法模式：父类定义
process()框架，留空钩子beforeValidate()和afterSave()，子类只覆写钩子，不碰主流程契约 - 组合优于继承：把“增强逻辑”抽成策略对象，例如父类
PaymentProcessor持有FeeCalculator接口，子类换实现，而非重写calculateTotal() - 若必须重写，用守卫断言显式声明约束：在子类
withdraw()开头加assert balance >= amount : "balance check violated";，比静默失败更容易暴露问题
IDE 和测试怎么帮我们守住 LSP
没有自动检查工具，但可以低成本拦截大部分问题：
立即学习“Java免费学习笔记（深入）”；
- 给父类每个 public 方法写契约式测试（比如“输入负数应抛
IllegalArgumentException”），所有子类共用同一套测试用例 —— 这比文档可靠得多 - IntelliJ 中开启 “Inheritance hierarchy” 视图，右键父类方法 → “Find Usages” → 切到 “Implementations” 标签页，一眼看出哪些子类重写了它，立刻人工核对行为一致性
- 避免在子类中出现
if (this instanceof SubClass)分支：这是典型的“向下类型检查”，说明父类抽象已失效，LSP 实际已被放弃
真正难的不是写对一个子类，而是在新增第 7 个子类时，还能确保前 6 个的调用逻辑不受影响——这时候契约测试和小步重构比设计模式更重要。
