里氏替换原则要求子类必须严格遵循父类契约：异常类型不可拓宽、前置条件不可加强、后置条件与不变量不可削弱，且禁止用继承模拟“has-a”关系，否则将导致编译失败或运行时隐性崩溃。
子类重写父类方法时抛出更宽泛异常
里氏替换原则（LSP）要求子类对象能无缝替代父类对象，但若子类方法抛出父类未声明的检查型异常，调用方代码会直接编译失败。这不是运行时问题，而是静态契约被破坏。
- 父类
save()声明throws IOException，子类重写后却throws Exception—— 调用方原逻辑不处理Exception，编译报错：unreported exception Exception; must be caught or declared to be thrown - 常见于“为了兜底加个 try-catch-throw new RuntimeException()”之外的错误做法：比如误把
SQLException包装成Exception向上抛 - 修复方式不是“统一改成 RuntimeException”，而是严格遵循父类异常签名；若真需扩展错误语义，应定义新的受检异常并继承父类已声明的异常类型
子类覆盖父类方法后改变前置条件（Precondition）
父类方法允许 null 输入，子类重写后加了 Objects.requireNonNull() 校验，就违反 LSP —— 外部代码传 null 给父类能跑通，换成子类就 NullPointerException。
- 典型场景：父类
process(String data)内部容忍data == null并返回默认结果；子类实现里第一行就if (data == null) throw new IllegalArgumentException() - 这种校验看似“更健壮”，实则让子类无法替代父类使用，尤其在依赖注入或工厂返回抽象类型时会静默崩溃
- 正确做法是：前置条件只能削弱（如父类要求非空，子类允许 null），不能加强；若业务真需要校验，应在更高层（如 API 入口）做，而非污染领域模型契约
子类修改父类方法的后置条件（Postcondition）或不变量（Invariant）
父类保证方法返回非 null，子类返回 null；或者父类维护某个字段单调递增，子类重写后重置它——这类行为变化会让依赖父类契约的代码意外失效。
- 例如父类
getUserById(long id)文档/测试均表明“必返回 User 对象”，子类实现因缓存未命中直接返回null，上游代码不做判空就 NPE - 又如父类
Counter的increment()保证value >= 0且只增不减，子类重写时加入“超限归零”逻辑，破坏了调用方对单调性的假设 - 检测手段：看父类 Javadoc、单元测试断言、以及所有显式或隐式的“保证”；子类不能缩小返回值范围、不能放宽/收紧状态约束
用继承模拟“has-a”关系（比如用 ArrayList 继承自 List）
Java 中 ArrayList 是 List 的实现，但它没继承 List 接口——因为接口不能继承，而类继承接口用 implements。但开发者常误让工具类继承集合类，以为“复用代码”，结果彻底违背 LSP。
立即学习“Java免费学习笔记（深入）”；
- 写一个
class SafeList extends ArrayList<string></string>，并在构造时自动过滤 null —— 表面看合理，但SafeList无法替代ArrayList：调用方若执行list.ensureCapacity(100)，父类行为被继承，但子类语义上“容量”可能毫无意义 - 更隐蔽的问题：
SafeList继承了所有ArrayList的 public 方法（如trimToSize()、removeRange()），这些方法绕过你的过滤逻辑，直接操作底层数组 - 真正该做的是组合：
class SafeList { private final List<string> delegate = new ArrayList(); }</string>，只暴露你控制得住的行为
最麻烦的不是语法报错，而是那些没写进文档、没进测试、只在特定分支路径才触发的契约破坏——它们让替换子类像拆一颗松动的螺丝，表面没事，震动一大就散架。
