virtual关键字是否天生违反里氏替换原则（LSP）？

你对里氏替换原则（LSP）的核心边界存在一个非常普遍的误解：LSP从来没有要求子类必须和基类保持完全相同的行为实现，它约束的是子类不能破坏基类对外公开的所有契约约定。

这里的契约包括但不限于：

• 方法的前置条件（调用方需要满足的输入要求）
• 方法的后置条件（方法执行完成后必须满足的输出约定）
• 类的不变式（类实例在任何公开操作执行前后都要保持的固定规则）
• 对外承诺的所有副作用约束

virtual/override关键字的设计初衷，本来就是允许子类在不突破上述契约的前提下，提供适配自身场景的差异化实现，这和LSP的要求不仅不冲突，反而是面向对象多态特性的合法使用方式。

举个非常常见的合法场景：
基类LogWriter有一个virtual void Write(string content)方法，契约约定：传入非空的content参数后，内容会被持久化到存储介质中。你可以派生FileLogWriter重写该方法把内容写到磁盘文件，派生DbLogWriter重写该方法把内容写到数据库，派生CloudLogWriter重写该方法把内容上传到对象存储。三者的具体行为完全不同，但都遵守了基类的契约，不管用哪个子类替换基类，上层调用打印日志的逻辑都不会出现异常，完全符合LSP的要求。

只有当重写virtual方法时突破了基类的契约，才会违反LSP，比如：

• 基类约定方法不会抛出业务异常，子类重写时新增了异常抛出逻辑
• 基类约定返回值永远为非负数，子类重写时会返回负数值
• 基类约定操作不会修改输入参数的状态，子类重写时擅自修改了入参的属性

这些问题的本质是继承设计的不合理，和virtual关键字本身没有关系。就算你不用virtual重写，子类自己新增一个同名方法破坏契约，一样是违反LSP的设计。

你感知到的「灰色地带」，大多源于很多基类设计时没有把契约明确落地（仅靠注释甚至口头约定约束），导致子类重写时无意间突破了边界，这是开发流程的问题，不是LSP或者virtual机制的设计问题。

内容的提问来源于stack exchange，提问作者gspetsnaz