里氏替换原则要求子类行为与父类契约完全兼容，调用方不改代码换用子类仍结果正确、异常可控、语义一致；禁止收紧前置条件、放松后置条件、新增未声明异常、破坏隐含契约；语义不符时应改用接口或抽象基类；需通过父类测试套件验证LSP合规性。

子类能安全替换父类，关键不在“能不能覆盖”，而在于“替换了是否还守约”。里氏替换原则（LSP）不是禁止覆盖，而是要求子类行为必须与父类的契约完全兼容——调用方不改一行代码，换上子类对象后，结果依然正确、异常仍可控、语义不偏移。

别让子类悄悄改掉父类的“承诺”

父类方法对外声明了什么，子类就得照做，不能偷换概念。比如父类 setLength() 表示“只设长、不影响宽”，子类若重写后顺手把宽也重置为和长一样，就破坏了调用方对“独立设置”的预期。

• 非抽象方法尽量不重写；真要重写，必须保证前置条件不收紧、后置条件不放松
• 父类方法声明返回 int，子类不能返回 long 或 null（除非父类已允许）
• 父类没声明抛异常，子类不能新增 throws IOException 这类未预告的异常

用抽象代替“假继承”，从源头规避风险

当父子类语义本质不同（如“正方形不是长方形”），硬套继承必然踩坑。这时应提取共性接口或抽象基类，让两者平级实现，而非上下级继承。

• 把“四边形”定义为接口，Rectangle 和 Square 各自实现 getLength()、getWidth()
• 若必须有公共基类，让它成为抽象类，把可变行为声明为 abstract，强制子类重新定义而非覆盖已有逻辑
• 避免让可实例化的具体类之间形成继承链，尤其当它们业务含义不构成“is-a”关系时

测试是验证LSP最直接的方式

写一组针对父类的单元测试（包括正常路径、边界值、异常场景），然后把父类对象换成子类对象再跑一遍——全通过，才说明子类真正满足LSP。

• 重点覆盖：输入相同参数时输出是否一致、是否多抛/少抛异常、是否改变对象内部状态的隐含契约
• 如果某测试在子类下失败，不要急着改测试，先问：是父类契约写得模糊？还是子类越界了？
• 对关键基类提供“LSP合规性检查套件”，作为CI流水线一环，防止后续修改意外破坏兼容性

方法签名宽松 ≠ 行为宽松，别被语法骗了

子类方法参数类型可以更宽泛（比如父类接受 String，子类接受 CharSequence），但这只是语法层面的兼容；真正的考验是：调用方传一个原本对父类安全的输入，在子类里是否依然安全？

• 父类 process(List) 允许空列表；子类若重写后对空列表抛 NPE，就违反LSP
• 父类文档说“该方法线程安全”，子类实现就不能变成非线程安全，哪怕签名完全一样
• 契约不仅藏在代码里，也在注释、文档、历史行为中——维护它需要读，不只是写