很多年前我还在做电商系统的时候，碰到过一个很邪门的 bug：订单结算时，只要命中某个促销规则，金额就会少算几块钱。测试环境怎么都复现不了，线上却偶发。那天下午，我带着两个后端同事把链路翻了底朝天，最后停在一行代码上：一个正方形类继承了长方形类。

我是老李。今天想和你聊的是设计模式里最容易被忽略、却最值钱的一条：里氏替换原则。

现在微服务接口越来越多，继承和实现每天都在发生，但真正理解“替换”的人不多。很多人以为只要编译通过、单测绿了，就万事大吉。可是里氏替换原则会告诉你：父类能跑的地方，子类未必能跑。

## 01、痛点

┌──────────────────┐
│    Rectangle     │
│  setWidth(int)   │
│  setHeight(int)  │
└──────────────────┘
          ▲
          │ extends
┌──────────────────┐
│      Square      │
│  setWidth(int)   │
│  setHeight(int)  │
└──────────────────┘

我先还原一下那个让人血压升高的代码。系统中有一个 Rectangle 类，负责矩形的宽高和面积。为了少写一个类，开发同事让 Square 直接继承 Rectangle，并重写 setWidth 和 setHeight：无论设置哪一项，都同时修改宽和高。

```
public class Rectangle {
    private int width;
    private int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(int height) {
        super.setWidth(height);
        super.setHeight(height);
    }
}
```

光看类本身，很多人会觉得没问题，正方形不就是一种特殊的矩形吗？问题出在调用方。促销规则里有个 resize 方法，它接收 Rectangle，先设置宽，再设置高，然后按矩形公式计算面积。

```
public void resize(Rectangle rectangle, int width, int height) {
    rectangle.setWidth(width);
    rectangle.setHeight(height);
    if (rectangle.getArea() != width * height) {
        throw new IllegalStateException();
    }
}
```

当外部传入普通 Rectangle 时，一切正常；当传入 Square 时，setWidth(5) 已经把高改成 5，setHeight(3) 又把宽改成 3，最终面积变成 9，而不是期望的 15。线上订单金额因此少算。

这不是继承语法错误，而是行为违约。父类 Rectangle 提供了一种宽松的、宽高互不干扰的设定方式；子类 Square 改变了这个约定。调用方基于父类契约编写，结果被子类破坏。

更糟的是，这类问题很难在开发阶段发现。因为单测如果只覆盖 Square 自己，所有断言都能过；只有把 Square 放到所有使用 Rectangle 的地方去替换时，才会暴露。

## 02、是什么

调用方 ── uses ──▶  父类型 T
                     ▲
                     │ 可替换
                     │
                    子类型 S

里氏替换原则的英文是 Liskov Substitution Principle，由 Barbara Liskov 在 1987 年提出。正式表述有点绕：如果对每一个类型为 T 的对象 o1，都有类型为 S 的对象 o2，使得以 T 定义的所有程序 P 在 o1 都换成 o2 时，程序 P 的行为没有变化，那么 S 是 T 的子类型。

翻译成 Java 场景：只要父类或接口能出现的地方，子类或实现类出现后，调用方不应该察觉到区别，更不应该因为换了类型而修改逻辑。

注意，这里说的是行为没有变化，不是编译通过。Java 编译器只检查方法签名和类型是否兼容，不检查语义。LSP 关注的正是语义层的可替换性。

判断一个子类是否满足 LSP，通常看三个契约：

第一，前置条件不能加强。父类方法对入参的要求，子类不能更严格。比如父类方法接受 0 到 100 的金额，子类不能只接受 0 到 50，否则调用方按父类约定传 80 就会失败。

第二，后置条件不能减弱。父类方法承诺返回非空结果，子类就不能返回 null；父类承诺调用后余额不为负，子类就不能允许负数。

第三，不变量必须保持。不变量是对象在方法执行前后都保持成立的性质。矩形宽高独立是一种不变量，Square 破坏了它。

从 Java 语法角度看，子类可以重写父类方法，可以增加新能力，但不能推翻原有承诺。LSP 不是禁止重写，而是要求重写不改变契约。

## 03、为什么

                    ┌───────────┐
                    │  父类契约  │
                    └───────────┘
                   前置  后置  不变量
                     ▲     ▲     ▲
                     └─────┴─────┘
                        必须保持一致

为什么这条原则如此重要？因为它直接决定了多态能不能用。

Java 的核心优势之一是面向对象多态：我们可以面向 List 接口编程，而不关心具体是 ArrayList 还是 LinkedList。ArrayList 和 LinkedList 的行为足够接近，所以在大多数场景中可以互相替换，这正是 LSP 的体现。

但如果某个自定义集合类实现了 List，add 方法却直接抛出 UnsupportedOperationException，那么在使用 List 的通用逻辑里，一旦替换成这个类，程序就会炸。虽然 Java 里有些只读集合确实会这么做，但从严格 LSP 角度看，这已经破坏了 List 接口的后置条件。这也是为什么现代 Java 更倾向于用不可变集合的专门类型，而不是硬塞进可变接口。

LSP 还是开闭原则的基石。系统想做到对扩展开放、对修改关闭，前提是新扩展的子类必须能安全替换父类。否则每新增一个子类，调用方都要加一段 if-else 做类型判断，系统永远无法真正关闭。

不满足 LSP 的继承会产生隐性耦合。调用方表面上只依赖父类，实际上却必须了解每个子类的特殊行为。这种耦合不会出现在编译错误里，却会在某个深夜爆雷。

我见过最典型的腐化信号，就是业务代码里大量出现 instanceof 和强转。出现这种代码，通常不是因为调用方写得烂，而是继承体系本身已经违约。

## 04、架构

                   ┌──────────────┐
                   │    Account    │
                   └──────────────┘
                     /         \
          Withdrawable       FixedDeposit
                 \
                CurrentAccount

架构设计时，LSP 要求我们区分两个问题：概念上的 is-a 和行为上的 is-a。

正方形在数学上是一种矩形，但在行为上，它无法继承一个宽高独立变化的矩形。软件继承不能照搬现实分类，必须看方法契约是否兼容。

一个常见错误是鸟与企鹅。你定义一个 Bird 类，里面有 fly() 方法。绝大多数鸟能飞，于是企鹅继承 Bird 后重写 fly() 抛异常。概念上企鹅是鸟，但行为上它无法替换 Bird，因为调用飞行逻辑的代码会炸。正确做法是定义 Flyable 接口，只有会飞的鸟实现它。

```
interface Flyable {
    void fly();
}

class Sparrow implements Flyable {
    public void fly() {
        // 麻雀飞行
    }
}

class Penguin {
    // 不实现 Flyable，不在飞行场景出现
}
```

再比如账户体系。银行里有活期账户、定期账户。如果抽象出 Account 接口，包含 withdraw 方法，定期账户不支持提前支取，如果直接实现 Account 并在 withdraw 里抛异常，就违反了 LSP。更稳妥的做法是拆出 Withdrawable 接口。

```
interface Withdrawable {
    void withdraw(BigDecimal amount);
}

class CurrentAccount implements Withdrawable {
    public void withdraw(BigDecimal amount) {
        // 活期账户取现
    }
}

class FixedDepositAccount {
    // 不实现 Withdrawable，只提供定期到期逻辑
}
```

这样，所有需要取现能力的代码都面向 Withdrawable 编程，定期账户根本不会进入这个上下文。调用方不需要判断账户类型，也不会被动接收一个无法取现的对象。

架构上还有一条判断标准：如果你发现某个父类被继承后，需要不断在父类中增加 if 判断某类子类，或者子类大量空实现某个方法，那么这个继承大概率是错的。此时应该把能力拆分成更小的接口，或使用组合。

Java 中的 final 和 sealed 也是 LSP 的辅助工具。final 阻止不可控子类，sealed 把继承范围限制在已知类型中，让契约更容易推理。

## 05、实战

反例：Square extends Rectangle → 面积计算翻车
正例：Square 独立，或抽取 Shape 接口

下面我用 Java 代码把几个典型场景串起来。

第一个场景：矩形与正方形。

```
public interface Shape {
    int getArea();
}

public class Rectangle implements Shape {
    private int width;
    private int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

public class Square implements Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}
```

现在 Rectangle 和 Square 都实现 Shape，但 Square 不再继承 Rectangle。resize 方法如果只负责矩形宽高调整，就只接收 Rectangle，Square 不会进来；如果业务只需要面积，就面向 Shape 编程。两者各得其所，调用方不再被误导。

第二个场景：仓库接口的后置条件。

假设用户仓储接口约定：找不到用户时返回 Optional.empty()，而不是返回 null。

```
public interface UserRepository {
    Optional<User> findById(Long id);
}

public class DbUserRepository implements UserRepository {
    public Optional<User> findById(Long id) {
        // 从数据库查询
        return Optional.ofNullable(user);
    }
}

public class CacheUserRepository implements UserRepository {
    public Optional<User> findById(Long id) {
        // 从缓存查询
        return Optional.ofNullable(cachedUser);
    }
}
```

两个实现都遵守后置条件，所以调用方可以安全替换。如果某个实现改为找不到时返回 null，调用方一旦忘记判空就会空指针，这就是削弱后置条件。

第三个场景：方法签名与异常。

Java 允许子类重写方法时返回更具体的类型，这不会破坏 LSP。因为调用方拿到的仍然可以赋值给父类型返回类型。

```
class AnimalFactory {
    Animal create() {
        return new Animal();
    }
}

class DogFactory extends AnimalFactory {
    @Override
    Dog create() {
        return new Dog();
    }
}
```

但子类不能把参数收窄。比如父类方法参数是 Number，子类改成 Integer，这不是重写而是重载。调用方通过父类引用调用时仍然走 Number 版本，行为可能不一致。

```
class Calculator {
    Number add(Number a, Number b) {
        return a.doubleValue() + b.doubleValue();
    }
}

class BadCalculator extends Calculator {
    // 这不是重写，而是重载，容易误导调用方
    Integer add(Integer a, Integer b) {
        return a + b;
    }
}
```

受检异常也一样。子类不能抛出比父类更宽泛的异常，否则会破坏调用方的编译期契约。

第四个场景：公共契约测试。

为了自动化校验 LSP，可以为接口编写抽象测试类，所有实现类共享。

```
public abstract class UserRepositoryContractTest {
    protected abstract UserRepository createRepository();

    @Test
    public void shouldReturnEmptyWhenUserMissing() {
        UserRepository repository = createRepository();
        assertTrue(repository.findById(9999L).isEmpty());
    }
}
```

每个具体实现只要继承这个测试类并创建对应实例，就能验证自己是否满足接口契约。

## 06、洞见

语法 extends ──▶ 编译器放行
行为替换 ──▶ 测试与评审把关

里氏替换原则最容易被误读成一条语法规则。很多人以为只要 Java 编译通过，子类就自动满足 LSP。其实完全不是。

编译器能检查方法名、参数类型、返回类型、可见性，但检查不了 setWidth 是否把 height 也改了，检查不了 findById 是否偷偷返回 null。行为层的不兼容只能靠契约测试、代码评审和设计约束来保证。

所以 LSP 本质上是类型系统的行为契约。它要求我们把父类当成一份合同，子类只能补充条款，不能撕毁条款。

识别违反 LSP 的三个信号：一是调用方出现 instanceof 和强制转换；二是子类有空实现、返回 null、抛出 UnsupportedOperationException；三是注释里写着“该方法不支持”或“不要调用”。只要有这些味道，继承体系多半已经需要重构。

正方形与矩形还揭示了一个更深层的认知陷阱：现实中的分类关系不能直接当成代码中的继承关系。数学上的 is-a 是概念，软件中的 is-a 是行为。一个类能不能继承另一个类，不取决于名词像不像，而取决于契约是否兼容。

另一个常见误区是拿继承做代码复用。看到某个类有段逻辑想复用，直接 extends 一下，结果子类被迫继承一堆自己无法兑现的方法。代码复用更安全的方式是组合、委托、静态工具方法。LSP 从反向告诉我们：如果继承让子类很痛苦，就说明不该继承。

Java 的 final 和 sealed 值得重新认识。过去我们总觉得 final 限制扩展，但在大型系统里，限制不可控继承恰恰是保护 LSP 的手段。限制继承面，契约就能收敛。

## 07、行动

契约检查清单
├─ 前置条件不加强
├─ 后置条件不减弱
├─ 不变量保持
├─ 调用方零 instanceof
└─ 配置公共契约测试

落地 LSP 不需要复杂工具，关键是养成几个动作。

第一，写父类或接口前，先把契约写清楚。不要只写方法签名，还要写出入参范围、返回承诺、失败方式和不变条件。可以是注释，也可以是测试。

第二，评审子类时逐条对照契约。重写方法时，确认入参范围没有收窄，返回没有变弱，异常没有变宽。

第三，删除调用方的 instanceof 和强转。如果必须靠类型判断才能使用子类，应该优先调整抽象，而不是继续堆判断。

第四，建立接口的公共契约测试。像 UserRepositoryContractTest 那样，让每个实现类都跑同一套测试。新实现只有在通过全套契约测试后才能合入。

第五，不支持的操作用独立接口表达，而不是抛异常。假设某个类不需要某个方法，那它就不该实现包含这个方法的接口。

第六，合理使用 final 和 sealed，降低不可控继承的风险。

第七，定期查一遍代码中的空实现、UnsupportedOperationException 和注释“不支持”。这些地方往往是线上隐患。

最后，记住一个顺序：先定义契约，再考虑继承；先测试父类，再让子类通过同样的测试。

## 08、小结

继承让你少写代码，里氏替换原则让你不必重写事故。真正好的子类，不是长得像父类，而是站到父类的位置上不让系统察觉。

回到那天的电商 bug，我们最后没有修 Square 的逻辑，而是把 Square 从 Rectangle 继承关系中拆了出来。促销规则重新面向一个面积接口编程。少算的几块钱回来了，也让我从此明白：父类能跑，不代表子类能跑。

## 09、链接与概念说明

里氏替换原则与多态：多态是 Java 提供的机制，LSP 是使用多态时必须遵守的约束。没有 LSP 的多态，只会让系统更脆弱。

里氏替换原则与继承：继承语法只解决类型兼容，LSP 解决行为兼容。extends 通过编译不代表替换安全。

里氏替换原则与开闭原则：开闭原则要求对扩展开放、对修改关闭，LSP 保证扩展出来的子类不会破坏已有调用方。

契约式设计：LSP 的前置、后置、不变量思想来自契约式设计。理解这三个概念，可以更精确地描述接口契约。

延伸阅读：Barbara Liskov 1987 年的原始演讲《Data Abstraction and Hierarchy》；《架构整洁之道》中关于 LSP 的章节；《敏捷软件开发：原则、模式与实践》中对里氏替换原则的详细讨论。

很多年前我还在做电商系统的时候，碰到过一个很邪门的 bug：订单结算时，只要命中某个促销规则，金额就会少算几块钱。测试环境怎么都复现不了，线上却偶发。那天下午，我带着两个后端同事把链路翻了底朝天，最后停在一行代码上：一个正方形类继承了长方形类。

父类能跑，子类就一定能跑？从 Java 多态翻车讲透里氏替换原则

一个看似正确的继承，差点让订单金额算错。用 Java 实例拆解里氏替换原则的行为契约与落地方法。

架构师

编程语言

架构设计

后端

订单结算金额因正方形类继承长方形类导致少算的bug，揭示了里氏替换原则在微服务架构中的关键作用。本文从真实案例出发，解析前置条件、后置条件及不变量三大契约，展示如何通过接口拆分、契约测试等实战手段避免继承陷阱，确保子类安全替换父类，保障系统行为一致性。

软件开发

代码解释

数据库

编译器

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

父类能跑，子类就一定能跑？从 Java 多态翻车讲透里氏替换原则-腾讯云开发者社区-腾讯云

父类能跑，子类就一定能跑？从 Java 多态翻车讲透里氏替换原则

父类能跑，子类就一定能跑？从 Java 多态翻车讲透里氏替换原则

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐