1. 为什么“子类能替换父类”这句话，90%的人一用就翻车？

里氏替换原则（Liskov Substitution Principle，简称LSP）在设计模式教材里通常被浓缩成一句教科书式定义：“子类型必须能够替换掉它们的父类型。”听起来很干净，很数学，很优雅——但只要你真正在项目里写过继承、改过接口、重构过老代码，就会发现：这句话像一把没开刃的刀，握着它的人以为自己在切菜，结果一刀下去，系统崩了，日志炸了，测试全红了。

我第一次栽在这句话上，是在一个模拟项目X的订单状态机模块里。当时团队为了快速上线，把Order抽象为基类，派生出NormalOrder、VipOrder、TrialOrder三个子类。某天产品提了个需求：“试用订单不能取消，但可以过期自动失效。”开发同学很自然地重写了TrialOrder.cancel()方法，让它直接抛出UnsupportedOperationException。逻辑上似乎没问题——“试用订单不支持取消”，语义清晰。可紧接着，下游调用方的一段通用取消流程就崩了：

public void batchCancel(List<Order> orders) { for (Order order : orders) { order.cancel(); // 这里对 TrialOrder 抛异常，整个批次中断 } }

没人想到，这段看似安全的多态调用，会因为一个子类“拒绝执行父类承诺的行为”，导致整条业务链路断裂。更讽刺的是，所有单元测试都绿着——因为测试只覆盖了单个子类的独立行为，没人去验证“把子类塞进父类容器后是否还能无感运行”。

这就是LSP最常被误解的起点：它不是关于语法正确性，而是关于契约一致性；它不关心你能不能编译通过，而死磕你能不能在运行时被当作父类安全使用。关键词“替换”二字，本质是“行为契约的无缝承接”，而非“类名能塞进泛型参数”的表面兼容。

很多初学者会把LSP和“继承就要重用”混为一谈，甚至误以为“只要 extends 就天然满足LSP”。错。恰恰相反，LSP是一道高压红线——它要求你每写一个extends，都必须回答三个灵魂拷问：

• 父类方法的前置条件（比如参数范围、状态约束），我在子类里有没有偷偷收紧？
• 父类方法的后置条件（比如返回值含义、副作用边界），我在子类里有没有悄悄扩大或改变？
• 父类方法的不变量（比如某个字段在调用前后必须保持非空），我在子类实现里有没有破坏它？

这三个问题，一个答错，LSP就塌了半边。而现实是，90%的继承滥用，都倒在第一个问题上：子类偷偷加了比父类更严格的输入校验。比如父类save(String content)允许空字符串，子类FileOrder.save()却要求content != null && !content.trim().isEmpty()——这看起来很“严谨”，实则彻底破坏了多态的可替换性。调用方按父类契约传入空串，子类直接拒收，契约就断了。

所以，别再把LSP当成一句装饰性的设计格言。它是一份运行时的行为保险单：当你把子类实例交给任何只认父类签名的代码时，这张保单必须生效——不抛意外异常、不改变预期语义、不破坏上下文状态。下文我们就从真实踩坑现场出发，一层层拆解这张保单到底该怎么签、怎么验、怎么续。

2. 从“鸭子类型”到“契约类型”：LSP的本质不是语法，而是行为协议

很多人学LSP时，第一反应是联想到Python里的“鸭子类型”（Duck Typing）：“如果它走起来像鸭子，叫起来像鸭子，那它就是鸭子。”于是顺理成章地认为：“只要方法名和参数一样，就能替换。”这种理解在动态语言里看似成立，但在Java/C#等静态语言中，恰恰是LSP最大的认知陷阱。

我们来看一个经典反例——矩形与正方形。这是Gof原著里反复引用的案例，但多数人只记住了结论，没吃透推演过程：

class Rectangle { protected int width; protected int height; public void setWidth(int width) { this.width = width; } public void setHeight(int height) { this.height = height; } public int getArea() { return width * height; } } class Square extends Rectangle { @Override public void setWidth(int width) { super.setWidth(width); super.setHeight(width); // 强制宽高相等 } @Override public void setHeight(int height) { super.setHeight(height); super.setWidth(height); // 强制宽高相等 } }

语法上完全合法：Square继承自Rectangle，所有方法签名一致，编译零报错。但问题出在行为契约上。假设有一段通用测试代码：

void testRectangleArea(Rectangle r) { r.setWidth(5); r.setHeight(4); assert r.getArea() == 20; // 期望：5×4=20 }

当传入Rectangle实例时，断言通过；但当传入Square实例时，setWidth(5)会同时把高度设为5，接着setHeight(4)又把宽度设回4，最终getArea()返回16，而非预期的20。子类没有破坏语法，却彻底篡改了父类方法的因果关系——setWidth和setHeight本应是正交操作，但在Square里变成了强耦合的连锁反应。

这个例子揭示了LSP的核心：它要求子类必须维持父类所声明的行为语义，而不仅仅是方法签名。父类Rectangle的契约隐含着一条关键不变量：“setWidth和setHeight是独立的、可交换顺序的操作”。Square重写这两个方法时，没有尊重这条隐含契约，而是用新的业务规则（宽高必须相等）覆盖了它。结果就是：Square在语法上是Rectangle的子类，但在行为上已不再是它的“合法替代品”。

那么，如何识别这些隐含契约？我的经验是，把父类看作一份行为协议文档，逐条审查：

注意，这里的关键不是“Square该不该存在”，而是“Square该不该继承Rectangle”。事实上，Square完全可以作为独立类存在，或者通过组合（Square内部持有一个Rectangle）来复用逻辑，而不是用继承强行建立“is-a”关系。这正是LSP给我们的第一个硬核启示：继承不是为了代码复用，而是为了契约复用；当行为契约无法对齐时，宁可放弃继承，选择组合或接口。

在模拟项目X的后续迭代中，我们彻底重构了状态机：把Order从具体类改为接口，cancel()方法定义为“尝试取消，返回操作结果枚举”，TrialOrder实现时返回CANCELLATION_NOT_ALLOWED而非抛异常。这样，上游batchCancel()就能根据返回值做分支处理，而不是被异常打断。契约从“必须成功”降级为“明确告知结果”，反而让多态真正落地。

3. 实战避坑指南：5类高频LSP违规场景与修复方案

在带团队做代码评审的三年里，我整理出一份LSP违规“黑榜”，覆盖了85%以上的生产环境继承滥用问题。这些不是理论推演，而是从线上告警、测试失败、需求返工中血泪总结的真实案例。下面按风险等级排序，每类都附带可直接抄作业的修复模板。

3.1 场景一：子类偷偷收紧前置条件（最高危）

典型表现：父类方法声明接受宽泛参数，子类重写时增加校验，拒绝父类允许的输入。

真实案例：某支付网关SDK中，基类PaymentProcessor.process(PaymentRequest req)允许req.amount <= 0（表示测试用零元支付），但某银行子类BankAProcessor.process()校验req.amount > 0，导致测试环境批量失败。

根因分析：LSP要求子类的前置条件不能比父类更严格（即子类的前置条件集合 ≥ 父类的前置条件集合）。父类说“我能处理所有PaymentRequest”，子类却说“我只处理金额大于0的”，这就违背了“能替换”的基本前提。

修复方案：用“守门人模式”统一前置校验，或重构为策略模式。

// ❌ 错误：子类私自加校验 class BankAProcessor extends PaymentProcessor { @Override public ProcessResult process(PaymentRequest req) { if (req.getAmount() <= 0) { // 父类没这行！ throw new IllegalArgumentException("Amount must be > 0"); } // ... 处理逻辑 } } // ✅ 正确：校验上提到父类，子类专注业务逻辑 abstract class PaymentProcessor { public final ProcessResult process(PaymentRequest req) { if (req.getAmount() <= 0) { return ProcessResult.failure("Zero amount not allowed in production"); } return doProcess(req); // 模板方法，由子类实现 } protected abstract ProcessResult doProcess(PaymentRequest req); } class BankAProcessor extends PaymentProcessor { @Override protected ProcessResult doProcess(PaymentRequest req) { // 这里只写纯业务逻辑，不碰校验 return callBankAPI(req); } }

提示：如果你发现某个子类需要特殊校验，优先考虑是否该把校验逻辑提取到工厂或适配器层，而不是污染继承链。继承链应该只承载“怎么做”，不承载“能不能做”。

3.2 场景二：子类擅自扩大后置条件（次高危）

典型表现：父类方法承诺返回特定类型/范围，子类返回更宽泛类型或引入新副作用。

真实案例：日志服务基类Logger.log(Level level, String msg)保证“不抛出检查异常”，但某云厂商子类CloudLogger.log()在连接超时时抛出IOException，导致调用方未捕获而崩溃。

根因分析：LSP要求子类的后置条件不能比父类更宽松（即子类的后置条件集合 ⊆ 父类的后置条件集合）。父类说“我绝不抛检查异常”，子类却打破了这个承诺，调用方按契约写的代码必然失效。

修复方案：用装饰器包装异常，或定义更精确的异常体系。

// ❌ 错误：子类抛出父类未声明的检查异常 class CloudLogger extends Logger { @Override public void log(Level level, String msg) throws IOException { // 新增throws！ sendToCloud(msg); // 可能抛IOException } } // ✅ 正确：将检查异常转为运行时异常，或封装为统一错误码 class CloudLogger extends Logger { @Override public void log(Level level, String msg) { try { sendToCloud(msg); } catch (IOException e) { // 转为运行时异常，或记录错误码 throw new RuntimeException("Cloud log failed", e); // 或：logError(level, "Cloud log failed: " + e.getMessage()); } } }

注意：如果业务上必须区分异常类型，应在父类中提前声明基础异常（如LogException），让所有子类继承并细化，而不是各自为政。

3.3 场景三：子类破坏父类不变量（隐蔽但致命）

典型表现：父类维护某些状态约束（如字段非空、集合大小限制），子类在重写方法时未同步维护。

真实案例：配置管理器ConfigManager要求configMap始终非空（构造时初始化为空HashMap），但某子类CachedConfigManager在clearCache()中直接置空configMap = null，导致后续getConfig()NPE。

根因分析：不变量是父类契约的基石。LSP要求子类在所有可见操作后，都必须保证父类声明的不变量依然成立。configMap != null就是一条核心不变量，子类破坏它等于撕毁契约。

修复方案：用final修饰关键字段，或用防御性编程保护不变量。

// ❌ 错误：子类直接破坏不变量 class CachedConfigManager extends ConfigManager { private Map<String, Object> cache; public void clearCache() { cache = null; // 错！cache 应该是空Map，不是null configMap = null; // 更错！破坏父类不变量 } } // ✅ 正确：用空集合代替null，用final+private封装 abstract class ConfigManager { private final Map<String, Object> configMap = new HashMap<>(); // final保证不被重赋值 protected Map<String, Object> getConfigMap() { return Collections.unmodifiableMap(configMap); // 返回不可变视图 } public void putConfig(String key, Object value) { configMap.put(key, value); } } class CachedConfigManager extends ConfigManager { private final Map<String, Object> cache = new HashMap<>(); public void clearCache() { cache.clear(); // 清空内容，不破坏引用 } }

3.4 场景四：子类改变方法的线程安全性（易被忽略）

典型表现：父类方法是线程安全的（如用synchronized），子类重写时去掉同步，或反之。

真实案例：缓存工具SafeCache.get(K key)用synchronized保证并发安全，但某子类RedisCache.get()直接调用非线程安全的Jedis客户端，导致高并发下数据错乱。

根因分析：线程安全性是重要的行为契约。父类承诺“多线程调用get()是安全的”，子类若不遵守，就等于在并发场景下制造了随机故障，极难复现和定位。

修复方案：将同步逻辑提到模板方法，或明确标注线程安全级别。

// ✅ 推荐：用模板方法固化同步契约 abstract class Cache<K, V> { public final V get(K key) { synchronized (this) { // 同步块在父类，子类无法绕过 return doGet(key); } } protected abstract V doGet(K key); } // ✅ 或：用接口+注解明确契约 interface ThreadSafeCache<K, V> { /** * 线程安全的获取操作。调用方无需额外同步。 * @throws CacheException 若底层存储不可用 */ V get(K key) throws CacheException; }

3.5 场景五：子类引入新方法但未提供默认实现（破坏多态完整性）

典型表现：子类添加了父类没有的方法，导致依赖父类的代码无法访问新能力，而子类又无法被安全“降级”使用。

真实案例：DatabaseConnection基类有connect()、execute()，某子类ShardingConnection新增routeToShard(String table)，但上游代码只能拿到DatabaseConnection引用，无法调用分片路由。

根因分析：这不是直接违反LSP（因为LSP只约束“能替换”，不约束“能扩展”），但它暴露了设计缺陷：当子类需要新能力时，说明父类契约本身就不完整。强行用继承扩展，会导致调用方必须做instanceof判断，破坏多态初衷。

修复方案：用接口隔离变化，或采用组合优于继承。

// ❌ 错误：继承链上硬塞新方法 class ShardingConnection extends DatabaseConnection { public void routeToShard(String table) { /* ... */ } } // ✅ 正确：定义新能力接口，由需要的类实现 interface Shardable { void routeToShard(String table); } class ShardingConnection extends DatabaseConnection implements Shardable { @Override public void routeToShard(String table) { /* ... */ } } // 调用方按需使用 void handleSharding(Shardable conn) { conn.routeToShard("orders"); }

4. LSP合规性自检清单：5分钟完成一次继承契约审计

光知道哪些地方会翻车还不够，你得有一套快速、可落地的检查流程，把它变成日常开发肌肉记忆。我在模拟项目X的Code Review Checklist里，把LSP检查固化为5个必答问题，每次提交前花5分钟过一遍，能拦截90%的继承滥用。这套清单不依赖IDE插件，纯靠人工阅读+逻辑推演，但极其有效。

4.1 问题一：前置条件对比表（必须画出来）

拿出纸笔（或新建文本文件），对照父类和子类的每个重写方法，列出它们的显式参数约束和隐式状态约束。填表时务必具体，拒绝模糊描述。

提示：隐式约束常藏在父类文档或历史commit里。比如父类注释写着“此方法在初始化后调用”，那“对象已初始化”就是一条隐式前置条件，子类重写时不能要求“对象必须已配置完成”。

4.2 问题二：后置条件映射图（重点查副作用）

对每个重写方法，画出“输入→输出→副作用”三要素映射。特别关注：返回值类型是否拓宽？是否新增了父类未声明的异常？是否修改了父类保证不修改的字段？

父类 save(Config c): 输入: c.id="A", c.data="old" 输出: true 副作用: configMap.put("A", "old"); // 仅修改configMap 子类 save(Config c): 输入: c.id="A", c.data="old" 输出: SaveResult.success() // 类型拓宽，但可接受 副作用: configMap.put("A", "old"); auditLog.append("Saved A by user X"); // 新增审计日志！父类没承诺

判断标准：新增副作用必须是幂等的、无害的、可被调用方忽略的。审计日志符合，但“发送邮件通知”就不符合——因为调用方没预料到会有邮件发出。

4.3 问题三：不变量快照（运行时验证）

找出父类声明的所有不变量（通常在类注释、构造函数、getter/setter注释中），对每个子类，手写一段“不变量快照”代码，在关键方法调用前后打印状态：

// 在子类关键方法前后插入 void debugInvariantSnapshot() { System.out.println("Before: configMap=" + configMap + ", cacheSize=" + cache.size()); // ... 执行业务逻辑 ... System.out.println("After: configMap=" + configMap + ", cacheSize=" + cache.size()); }

运行单元测试，观察输出。如果After行显示configMap=null而父类契约要求非空，立刻修正。

4.4 问题四：多态调用沙盒（最小化验证）

创建一个极简的“沙盒测试”，只验证“子类能否被父类容器无感使用”：

@Test void liskovSubstitutionTest() { // 1. 构造父类引用，指向子类实例 PaymentProcessor processor = new BankAProcessor(); // 2. 调用所有父类公开方法，覆盖边界值 processor.process(new PaymentRequest(0)); // 测试零元 processor.process(new PaymentRequest(-100)); // 测试负数 processor.process(new PaymentRequest(1000000)); // 测试大额 // 3. 验证结果符合父类契约（不抛异常、返回值合理） // 如果这里任何一个调用失败，LSP即不满足 }

这个测试不验证业务逻辑，只验证“不崩、不抛意外异常、返回类型正确”。它是LSP的终极裁判。

4.5 问题五：继承必要性投票（灵魂拷问）

最后，对本次继承决策进行一次严肃投票：

• ✅必须继承：子类需要复用父类大量非私有状态和行为，且行为契约100%对齐（通过前4步验证）。
• ⚠️建议组合：子类只复用父类部分行为，或契约有细微差异（如日志格式不同）。此时应让子类持有父类实例，通过委托调用。
• ❌禁止继承：子类只是“看起来像”父类，或需要覆盖大部分方法，或业务语义根本不同（如Square和Rectangle）。

我的经验是：如果投票结果是⚠️或❌，立刻停止编码，重画类图。节省的不是5分钟，而是未来三天的线上排查时间。

5. 当LSP遇上现代架构：微服务、函数计算与领域驱动设计中的新挑战

LSP诞生于面向对象单体应用时代，但今天我们的代码跑在K8s集群里、部署在Serverless平台上、按领域边界拆分成数十个微服务。这些架构演进没有削弱LSP的价值，反而让它以更隐蔽、更致命的方式浮现。我带过的几个跨平台系统项目，LSP问题往往不在代码里，而在服务契约和数据模型中。

5.1 微服务间的LSP：API契约即继承契约

在微服务架构中，“继承”从语言特性升维为跨进程契约。一个HTTP API的OpenAPI规范，本质上就是一份“远程父类接口”。而各服务的实现，就是它的“分布式子类”。

比如订单服务定义了POST /v1/orders接口，契约规定：

• 请求体：{ "amount": number, "currency": string }
• 响应：201 Created+{ "id": string, "status": "created" }
• 错误：400 Bad Request（参数校验失败）

某新接入的跨境支付子服务，为了风控，悄悄在请求体中增加了"riskLevel": "low|medium|high"字段，并要求必填。这看起来是“增强功能”，实则是LSP违规：

• 前置条件收紧：父契约允许无riskLevel的请求，子服务拒绝；
• 后置条件扩大：响应体新增"riskAssessment"字段，调用方解析失败；
• 不变量破坏：父契约保证status字段值域为["created", "failed"]，子服务新增"pending_risk_check"。

解决方案不是让所有服务削足适履，而是建立契约治理中心：

• 所有API变更必须经契约委员会评审，LSP合规性是硬性否决项；
• 使用x-extension字段承载扩展信息，主契约保持稳定；
• 为不同风控等级的服务，定义独立的API版本（/v1/orders/risk-high），而非污染通用接口。

5.2 函数计算中的LSP：事件驱动下的行为一致性

Serverless函数（如AWS Lambda、阿里云FC）常以事件为输入。一个OrderCreatedEvent事件结构，就是所有消费该事件的函数的“父类”。而InventoryService.handle(event)、NotificationService.handle(event)等，就是它的“子类实现”。

LSP在这里表现为：所有消费者必须能处理同一份事件，且行为语义一致。常见违规是：

• 某函数要求event.orderItems非空，另一函数允许空数组；
• 某函数将event.timestamp解释为“创建时间”，另一函数解释为“支付时间”；
• 某函数在处理失败时发OrderProcessingFailed事件，另一函数静默丢弃。

修复核心是事件建模即契约建模：

• 用Avro或Protobuf定义强类型事件Schema，字段标记required/optional；
• 为每个字段添加语义注释（如"timestamp": "UTC time when order is placed"）；
• 消费者函数启动时，加载Schema并校验事件结构，不匹配则打标并告警，而非直接失败。

5.3 领域驱动设计（DDD）中的LSP：聚合根与值对象的边界守护

在DDD中，LSP是检验“聚合设计是否合理”的黄金标尺。一个经典的反模式是：把Customer（聚合根）和VipCustomer（子类）放在同一聚合内，认为“VIP客户是客户的一种”。

但LSP立刻戳破泡沫：

• Customer.changeAddress()允许地址变更，VipCustomer.changeAddress()可能需要额外审批流；
• Customer.delete()软删除，VipCustomer.delete()需同步清理关联的VIP权益；
• 父类契约“删除客户即结束客户关系”，子类却引入“VIP关系可恢复”的新语义。

正确做法是：用领域事件解耦，而非继承。

• Customer聚合根发布CustomerAddressChanged事件；
• VipCustomerPolicy（独立聚合）订阅该事件，决定是否触发审批；
• VipCustomer作为值对象嵌入Customer，或作为独立聚合存在，通过ID关联。

这样，Customer的契约纯净，VipCustomer的复杂逻辑被隔离，LSP自然成立。

最后分享一个个人体会：LSP不是用来“证明设计正确”的，而是用来“提前杀死错误设计”的。每次你想写extends时，先花两分钟问自己：“如果我把这个子类实例，塞进所有只认识父类的地方，它会不会安分守己？”答案是否定的，那就别写。设计模式的智慧，不在于炫技，而在于克制。