里氏替换原则（LSP）是设计契约，要求子类对象可无损替换父类对象：前置条件不得强化、后置条件不得弱化、行为与副作用须一致；违反案例包括正方形继承长方形、企鹅继承鸟类等；践行要点为优先抽象/接口、避免重写公开方法、用模板方法、明确契约文档、执行子类替换测试。
里氏替换原则（Liskov Substitution Principle，简称 LSP）不是语法规定，而是一条设计契约：只要代码中用到了父类类型的地方，换成它的任意子类对象，程序逻辑必须依然正确、行为不能改变。
核心是“行为可替换”，不是“语法能编译”
Java 编译器允许子类重写父类方法，但 LSP 要求这种重写不能破坏原有语义。比如：
- 父类方法声明接收 int 参数且要求 ≥ 0，子类重写后不能改成只接受偶数——这强化了前置条件，调用方可能传入 1 而崩溃；
- 父类方法保证返回非 null 的 List，子类就不能返回 null——这弱化了后置条件，上层空指针风险陡增；
- 父类的
withdraw(double amount)方法扣款成功后更新余额并返回 true，子类若重写为“余额不足也返回 true 但不扣款”，就违反了行为一致性。
Java 中典型的违反场景
这些例子在真实项目里高频出现，容易被忽略：
-
正方形继承长方形：长方形有独立的
setWidth()和setHeight()，但正方形重写这两个方法强制宽高同步。结果：传入Rectangle r = new Square()后调用r.setWidth(5); r.setHeight(3)，实际得到的是边长为 3 的正方形，面积从预期的 15 变成 9； -
企鹅继承鸟类：若
Bird有fly()方法，Penguin重写为抛异常或空实现，那么所有面向Bird编写的飞行调度逻辑（如if (bird.canFly()) bird.fly();）在传入企鹅时就会出错或跳过关键流程； -
子类偷偷改变方法副作用：父类
saveUser()只写数据库，子类重写后额外发短信、改缓存、触发异步任务——调用方没预料到这些动作，可能造成重复通知或事务不一致。
怎么写出符合 LSP 的 Java 继承结构
关键不是“能不能继承”，而是“该不该用继承”。推荐做法：
立即学习“Java免费学习笔记（深入）”；
- 优先把共性提取到 抽象类或接口，让子类实现而非继承具体行为；
- 如果必须继承，子类只 添加新方法，避免重写已有公开方法；确需定制逻辑，用 模板方法模式（父类定义 final 流程，留 abstract 钩子）；
- 对可能被多态调用的方法，用 Javadoc 明确标注前置条件（@param）、后置条件（@return）、异常（@throws）和不变量（@see Invariant）；
- 测试时做“子类替换测试”：把单元测试中所有父类实例替换成子类实例，看是否全部通过——这是验证 LSP 最直接的方式。
它和多态、开闭原则的关系
LSP 是多态真正可用的前提。没有它，List<animal> animals = Arrays.asList(new Dog(), new Cat()); animals.forEach(Animal::makeSound);</animal> 这样的代码就只是语法糖，运行时可能一个叫得欢、一个静默、一个抛异常。它也是开闭原则（对扩展开放、对修改关闭）的支撑：只有子类能安全替换父类，你才能放心加新子类而不动老代码。
