1. 为什么里氏替换原则值得单独拎出来讲

很多人第一次接触设计模式相关的知识时，注意力往往被单例、工厂、观察者这些“能直接看到效果”的模式吸引，而里氏替换原则这种听起来像学术名词的东西，常常被一笔带过。但我自己在实际项目里踩过几次坑之后才发现，里氏替换原则（Liskov Substitution Principle，简称LSP）才是继承体系里最容易出事、也最容易被忽视的一条底线。它不像某个具体模式那样给你一个现成的代码模板，它更像是一条“契约”，告诉你什么时候可以用继承，什么时候用了继承反而会把代码带进沟里。

先把话说清楚：里氏替换原则的核心定义是——所有引用基类的地方，必须能透明地使用其子类的对象。换句话说，如果一段代码用的是父类类型，那么把任何一个子类对象塞进去，程序的行为都应该符合预期，不能出现“换个儿子就翻脸”的情况。这个原则最早由芭芭拉·利斯科夫在1987年提出，后来被纳入SOLID五大设计原则中的“L”，是面向对象设计里关于继承关系的根本约束。

那它到底解决了什么问题？简单讲，它解决的是继承滥用导致的隐性bug和逻辑混乱。继承是面向对象里最容易被滥用的特性之一，因为它写起来太方便了——extends一敲，父类的方法全都有了。但方便不等于正确。如果子类改掉了父类方法的行为语义，或者子类根本不支持父类的某些能力，那么所有依赖父类接口的代码都会变得不可靠。你以为是多态，实际上是埋雷。

这篇文章适合谁看？如果你写过继承、用过多态、或者在代码review里被人说过“这个继承关系不太对”，那这篇内容就是给你准备的。我会从设计思路、核心细节、实操代码、常见问题四个维度，把里氏替换原则彻底拆开讲透，尽量用生活化的类比和可直接复现的代码，让你不仅知道它是什么，更知道怎么在项目里落地。

2. 里氏替换原则的整体设计思路拆解

2.1 继承的本质是“is-a”还是“is-like-a”

很多人对继承的理解停留在“子类是一种父类”这个层面，也就是所谓的is-a关系。比如“狗是一种动物”“圆形是一种形状”，这种关系天然适合继承。但实际开发中，大量继承关系其实是is-like-a——子类“像”父类，但并不完全具备父类的能力。这两种关系的混淆，是违反里氏替换原则的根源。

我举个常见的例子。假设有一个Bird类，里面有个fly()方法。然后你写了一个Ostrich（鸵鸟）类继承Bird。从生物学分类上说，鸵鸟确实是鸟，is-a关系成立。但鸵鸟不会飞啊，于是你在Ostrich里把fly()重写成抛异常或者空实现。这时候问题就来了：任何拿着Bird引用调用fly()的代码，传进去一只鸵鸟就会炸。这就是典型的违反LSP。

正确的做法是什么？要么把fly()从Bird里拿出去，单独定义一个Flyable接口，让会飞的鸟去实现；要么重新设计继承体系，让Bird只保留所有鸟都具备的能力。这个判断过程，就是里氏替换原则在帮你做设计决策。

2.2 契约式设计：前置条件、后置条件与不变式

里氏替换原则背后其实有一套更严谨的理论支撑，叫做契约式设计。父类的方法定义了一份“契约”，包含三个部分：

• 前置条件：调用这个方法之前必须满足的条件，比如参数不能为null、数值必须为正数。
• 后置条件：方法执行完之后保证成立的状态，比如返回值不为null、集合大小会增加。
• 不变式：方法执行前后都必须保持成立的约束，比如账户余额不能为负。

子类在重写父类方法时，必须遵守以下规则：前置条件不能加强（子类不能要求比父类更多的条件），后置条件不能减弱（子类不能给出比父类更少的保证），不变式必须保持。这三条规则听起来抽象，但翻译成人话就是：子类只能比父类“更宽松”或“一样”，不能比父类“更严格”。

为什么？因为使用父类的地方，调用者只知道父类的契约。如果子类偷偷加强了前置条件，调用者按父类的规则传参，到了子类这里就不满足了，程序自然出问题。这就像你去餐厅点餐，菜单上写着“任意主食都可以”，结果你点了米饭，厨房说“我们米饭只供应给VIP”——这就是子类加强了前置条件，违反了契约。

2.3 为什么不用继承也能达到目的

里氏替换原则的一个隐含推论是：如果两个类之间不满足LSP，那就不应该用继承。那不用继承用什么？答案是组合、委托、接口实现。这三种方式比继承更灵活，也不会把子类绑死在父类的契约上。

组合的思路是“有一个”而不是“是一个”。比如Car类需要用到Engine的功能，不是让Car继承Engine，而是让Car持有一个Engine实例，通过调用engine.start()来使用。这样Car和Engine之间是松耦合的，Engine怎么改都不会影响Car的继承体系。

委托则是把某个方法的实现交给另一个对象去做。接口实现则是只约定行为，不约定实现，子类（实现类）只需要满足接口定义的方法签名和语义即可，没有父类具体实现的包袱。

这三种方式各有适用场景，但共同点是：它们都不会产生“子类必须兼容父类所有行为”的强制约束。当你发现继承关系开始变得别扭时，第一反应应该是考虑换成组合或接口，而不是硬着头皮在子类里写各种特殊判断。

3. 核心细节解析与实操要点

3.1 经典违规案例：正方形继承矩形

聊里氏替换原则，绕不开“正方形继承矩形”这个经典案例。这个例子虽然被讲烂了，但它确实精准地展示了LSP违规的全过程，我还是要拿出来说一遍，因为很多人只知道结论，不知道推导过程。

假设有一个Rectangle类，有setWidth()和setHeight()两个方法，还有一个getArea()方法返回宽乘高。现在让Square继承Rectangle，因为正方形也是矩形嘛。但正方形要求宽和高必须相等，所以Square的setWidth()和setHeight()需要同时设置两个值。

class Rectangle { protected int width; protected int height; public void setWidth(int w) { this.width = w; } public void setHeight(int h) { this.height = h; } public int getArea() { return width * height; } } class Square extends Rectangle { @Override public void setWidth(int w) { this.width = w; this.height = w; } @Override public void setHeight(int h) { this.width = h; this.height = h; } }

看起来没问题对吧？但如果有这样一段代码：

void resize(Rectangle r) { r.setWidth(5); r.setHeight(4); assert r.getArea() == 20; // 期望面积是20 }

传一个Rectangle进去，面积是20，断言通过。传一个Square进去，setWidth(5)把宽高都设成5，setHeight(4)又把宽高都设成4，最后面积是16，断言失败。这就是典型的LSP违规：子类改变了父类方法的行为语义，导致依赖父类契约的代码出错。

正确的设计是什么？不要让Square继承Rectangle。可以定义一个Shape接口，里面有getArea()方法，Rectangle和Square各自实现这个接口，互不继承。这样就没有契约冲突了。

3.2 方法重写时的参数与返回值约束

在Java、C#这类静态类型语言里，编译器对方法重写的参数和返回值有一定约束，但这些约束只覆盖了类型层面，覆盖不了语义层面。我整理了一个表格，把常见的约束和容易踩的坑列出来：

这张表里，前三条编译器能帮你检查一部分，后两条完全靠开发者自觉。而实际项目里出问题的，往往就是后两条。所以我在code review时，看到子类重写父类方法，第一反应就是去看它的语义有没有变。

3.3 里氏替换原则与开闭原则的联动

里氏替换原则很少单独发挥作用，它通常和开闭原则一起出现。开闭原则说“对扩展开放，对修改关闭”，而里氏替换原则保证了扩展的安全性——你新增一个子类，不需要修改使用父类的代码，因为子类可以透明替换父类。

这两条原则配合起来，才能实现真正的可扩展性。如果只有开闭原则没有LSP，你扩展出来的子类可能根本没法用；如果只有LSP没有开闭原则，你的继承体系虽然安全，但每次加功能都要改老代码，扩展性又没了。所以我在设计继承体系时，会同时问自己两个问题：这个子类能不能透明替换父类？新增这个子类需不需要改调用方的代码？

3.4 实操心得：什么时候该警惕LSP违规

根据我的经验，以下几种情况出现时，大概率已经违反了里氏替换原则：

• 子类方法里出现throw new UnsupportedOperationException()或类似“不支持此操作”的逻辑。
• 子类重写方法后，方法体里第一件事是判断“如果是什么情况就返回父类实现，否则走自己的逻辑”。
• 调用方代码里出现if (obj instanceof SubClass)这样的类型判断，然后针对子类做特殊处理。
• 子类重写方法后，父类的单元测试跑不过了。
• 子类需要访问父类的protected字段才能完成自己的逻辑，而且改动了这些字段的语义。

这五条里只要中了一条，就值得停下来重新审视继承关系。我自己的习惯是，在写子类之前先问一句：如果我把这个子类对象传给一个只认父类的方法，那个方法会不会出问题？如果答案是“可能会”，那就别用继承。

4. 实操过程与核心环节实现

4.1 从违规代码到合规设计的重构全过程

光讲理论不够，我拿一个实际项目里遇到过的场景来演示重构过程。假设我们在做一个支付系统，有一个Payment基类，定义了pay()方法。最初的设计是这样的：

abstract class Payment { public abstract void pay(double amount); public abstract void refund(double amount); }

然后有CreditCardPayment、WechatPayment、CashPayment三个子类。前两个都正常实现了pay()和refund()，但CashPayment的refund()没法实现——现金支付怎么退款？于是CashPayment的refund()直接抛了异常。

class CashPayment extends Payment { @Override public void pay(double amount) { System.out.println("现金支付：" + amount); } @Override public void refund(double amount) { throw new UnsupportedOperationException("现金支付不支持退款"); } }

这段代码上线后，问题很快就来了。订单系统里有一个批量退款的方法：

void batchRefund(List<Payment> payments, double amount) { for (Payment p : payments) { p.refund(amount); } }

这个方法按Payment的契约来写，认为所有支付方式都支持退款。结果传进去一个包含现金支付的列表，程序直接崩了。这就是LSP违规的典型后果。

4.2 重构方案一：拆分接口

最直接的修复方式是把refund()从Payment里拿出去，单独定义一个Refundable接口：

interface Refundable { void refund(double amount); } abstract class Payment { public abstract void pay(double amount); } class CreditCardPayment extends Payment implements Refundable { @Override public void pay(double amount) { System.out.println("信用卡支付：" + amount); } @Override public void refund(double amount) { System.out.println("信用卡退款：" + amount); } } class CashPayment extends Payment { @Override public void pay(double amount) { System.out.println("现金支付：" + amount); } }

这样batchRefund方法的参数类型改成List<Refundable>，只有支持退款的支付方式才能传进来，编译期就杜绝了违规调用。这个方案的好处是职责清晰，每个接口只约定一种能力，实现类按需实现。

4.3 重构方案二：用组合替代继承

如果业务上确实需要“所有支付方式都有退款能力”，但现金支付的退款逻辑不同（比如只能退到账户余额），那可以考虑用组合的方式。定义一个RefundStrategy接口，每个支付类持有一个退款策略：

interface RefundStrategy { void refund(double amount); } class CashRefundStrategy implements RefundStrategy { @Override public void refund(double amount) { System.out.println("退款到账户余额：" + amount); } } class Payment { private RefundStrategy refundStrategy; public Payment(RefundStrategy strategy) { this.refundStrategy = strategy; } public void refund(double amount) { refundStrategy.refund(amount); } }

这样Payment的refund()方法对所有子类（或实例）都有一致的语义，只是具体实现委托给了策略对象。调用方不需要关心退款是怎么实现的，只需要知道“调用refund就会退款”。这个方案比继承更灵活，因为退款策略可以在运行时替换。

4.4 参数校验与前置条件的处理技巧

在实现子类方法时，前置条件的处理是个容易出错的点。父类方法可能对参数有校验，子类重写时如果加了更严格的校验，就违反了LSP。我一般用这样的模板来写：

// 父类 public void transfer(String account, double amount) { if (account == null || amount <= 0) { throw new IllegalArgumentException("参数不合法"); } // 业务逻辑 } // 子类——正确做法：保持或放宽前置条件 @Override public void transfer(String account, double amount) { // 不加额外校验，或者只加比父类更宽松的校验 super.transfer(account, amount); // 子类特有逻辑 }

如果子类确实需要额外校验，那说明这个校验应该上移到父类，或者这个子类不应该继承父类。我见过有人在子类里加了一堆if判断，然后父类方法调用时各种绕过，最后代码变成一团乱麻。这种时候正确的做法是重新审视继承关系，而不是在子类里打补丁。

4.5 单元测试如何验证LSP合规性

验证里氏替换原则最有效的手段是针对父类写测试，然后用子类实例跑一遍。这个技巧我在多个项目里用过，非常管用。具体做法是：

abstract class PaymentTest { protected abstract Payment createPayment(); @Test public void testPay() { Payment p = createPayment(); p.pay(100); // 断言支付后的状态 } @Test public void testRefund() { Payment p = createPayment(); p.pay(100); p.refund(50); // 断言退款后的状态 } } class CreditCardPaymentTest extends PaymentTest { @Override protected Payment createPayment() { return new CreditCardPayment(); } } class CashPaymentTest extends PaymentTest { @Override protected Payment createPayment() { return new CashPayment(); } }

如果CashPaymentTest跑不过testRefund，那就说明CashPayment违反了LSP。这个测试模式的好处是，它把父类的契约固化成了测试用例，任何子类只要不满足契约就会暴露出来。我在团队里推行这个做法之后，继承相关的bug少了很多。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

5.2 避坑技巧：继承层次不要超过三层

这是我个人的经验之谈：继承层次尽量控制在两层，最多三层。超过三层之后，每一层的方法重写都会叠加契约约束，子类要满足所有祖先类的契约，难度指数级上升。而且调试的时候，一个方法调用要跳好几层才能找到实际执行的是哪个版本，维护成本很高。

如果发现继承层次要超过三层了，通常说明设计出了问题。这时候应该考虑用组合、策略模式、或者把中间层抽象成接口。我在一个项目里见过五层的继承体系，最底层的子类重写了十几个方法，每个方法里都有super.super.super的调用，那代码读起来简直是灾难。

5.3 避坑技巧：区分“行为继承”和“实现继承”

继承有两种用途：一种是继承行为（子类复用父类的逻辑），一种是继承接口（子类承诺实现父类的方法）。里氏替换原则主要约束的是行为继承。如果只是想让子类拥有父类的方法签名，但实现完全不同，那应该用接口而不是抽象类。

举个例子，List和ArrayList的关系是接口继承，ArrayList承诺实现List定义的所有方法，但具体怎么实现是自由的。而AbstractList和ArrayList的关系是行为继承，ArrayList复用了AbstractList的部分实现。这两种继承的约束强度不一样，行为继承的约束更强，因为子类不仅要满足接口契约，还要兼容父类的实现语义。

5.4 避坑技巧：用“替换测试”快速判断

每次写完一个子类，我都会做一个简单的“替换测试”：把代码里所有用父类的地方，手动替换成子类，看看逻辑还对不对。这个测试不需要真的改代码，在脑子里过一遍就行。如果发现某个地方替换后会出问题，那就说明这个子类违反了LSP。

这个测试的关键是不要只看编译能不能过，要看运行时行为对不对。编译能过只说明类型兼容，运行时行为一致才是LSP的要求。我见过太多代码编译没问题，一跑就出bug的情况，根源都是LSP违规。

5.5 避坑技巧：警惕“为了复用代码而继承”

这是最常见的LSP违规动机。开发者看到父类有个方法写得不错，想让子类直接用，就用了继承。但子类和父类之间可能根本没有is-a关系，只是碰巧需要同一个方法。这种情况下，正确的做法是把那个方法抽到一个工具类或者通过组合来复用，而不是用继承。

我的一般原则是：继承只用于表达类型层次关系，不用于复用代码。复用代码应该用组合、委托、或者工具类。这条原则帮我避免了很多LSP问题。每次我想用继承的时候，先问自己：这个子类真的“是”父类的一种吗？如果答案不是斩钉截铁的“是”，那就别用继承。

5.6 避坑技巧：接口设计要遵循接口隔离原则

里氏替换原则和接口隔离原则经常一起出现。接口隔离原则说“客户端不应该依赖它不需要的接口”，这其实也是在保护LSP。如果一个接口定义了太多方法，实现类很可能只需要其中一部分，剩下的只能抛异常或者空实现，这就违反了LSP。

所以设计接口时，要尽量细粒度。比如不要设计一个Animal接口里面有fly()、swim()、run()三个方法，而是拆成Flyable、Swimmable、Runnable三个接口，让不同的动物按需实现。这样每个实现类都只需要满足自己承诺的契约，不会出现“被迫实现不支持的方法”的情况。

5.7 避坑技巧：文档化父类的契约

最后一个技巧可能有点反直觉：把父类的契约写进文档注释。很多人觉得代码即文档，但契约这种东西，代码本身表达不了。比如一个方法承诺“返回值不为null”，代码里可能只是return result;，看不出这个承诺。但如果写在文档注释里，子类的开发者就能看到，重写时会注意保持这个承诺。

我一般会在父类方法的注释里写清楚：前置条件是什么、后置条件是什么、有没有副作用、异常情况怎么处理。这些信息对子类开发者来说非常宝贵，能帮他们避免无意中违反LSP。虽然写注释花时间，但比起后期调试LSP违规的bug，这点时间花得值。

6. 里氏替换原则在实际项目中的取舍

说了这么多，最后聊点实在的：里氏替换原则是不是必须严格遵守？我的答案是：在核心业务代码和公共API里必须严格，在内部工具类和临时脚本里可以适当放松。原因很简单，核心业务代码的继承体系会被大量调用，一旦LSP违规，影响面很大；而内部工具类通常只有少数几个地方用，出了问题也好改。

另外，LSP的遵守程度也和团队规模有关。小团队里大家互相了解代码，偶尔违反一下可能问题不大；但大团队里代码是多人维护的，一个人写的子类可能被另一个人调用，这时候LSP就是保证协作效率的重要约束。

我在实际项目里的做法是：在代码review清单里加上LSP检查项。每次有人提交涉及继承的代码，reviewer都要问一句“这个子类能不能透明替换父类”。这个习惯坚持下来之后，继承相关的bug明显减少，代码的可维护性也上了一个台阶。

里氏替换原则不是什么高深的理论，它本质上就是一句话：用父类的地方，换成子类也得能跑。但就是这么简单的一句话，在实际项目里能帮你避开大量的坑。希望这篇内容能让你在下一次写extends的时候，多想一秒钟。