JavaScript继承不自动保障里氏替换原则（LSP），其遵循依赖开发者设计：须保持子类方法语义与父类一致、维护父类不变量、优先组合替代继承，并辅以类型提示与运行时校验。

JavaScript 中的继承机制本身不强制约束行为语义，是否遵循里氏替换原则（LSP）取决于开发者如何设计构造函数、原型方法和子类逻辑。它不是语言特性自动保障的，而是设计决策的结果。

确保子类方法不破坏父类契约

父类定义的行为预期（比如方法的输入、输出、副作用、状态变化）必须被所有子类严格遵守。不能因为“重写”就改变原有语义。

• 例如：父类 Vehicle 的 accelerate() 每次使速度 +1；子类 FastVehicle 若改为 +3，表面看是“增强”，但若外部逻辑依赖“每次加速只增1”来控制状态（如判断是否达到某阈值），就会出错——这已违反 LSP。
• 正确做法是：保持 accelerate() 行为一致，把“加速更快”作为新能力单独暴露（如 boost()），或通过配置参数实现可扩展性，而非覆盖原方法。

避免在子类中篡改父类的不变量

父类维护的内部状态规则（invariants）必须在子类中依然成立。常见反例是正方形继承矩形：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 若 Rectangle 允许独立设置 width 和 height，而 Square 在 setWidth() 中同步修改 height，则用 Square 替换 Rectangle 会导致面积计算异常（如设宽=5、高=2，期望面积10，实际却变成25）。
• 解决方式不是强行继承，而是提取公共接口（如 Shape），让 Rectangle 和 Square 各自实现 getArea()，互不干扰。

优先使用组合/委托替代强继承

JavaScript 天然支持对象组合与函数复用，比模拟“类继承”更易满足 LSP。

• 用工厂函数或 Object.assign() 组合行为模块，比深继承链更可控；
• 例如：一个 Logger 类需要支持不同输出目标（console、file、network），与其让 ConsoleLogger 继承 Logger 并重写 log()，不如让 Logger 接收一个 transport 对象，由 transport 决定如何输出——这样任意 transport 实现都可替换，且不改变 Logger 的调用契约。

用类型提示和运行时校验辅助保障

虽然 JS 是动态语言，但可通过约定和轻量检查提升 LSP 可靠性：

• 在关键方法入口做参数类型/范围校验（如 decelerate() 不允许速度低于 0）；
• 对返回值做基本断言（如 state() 总是返回预设字符串之一）；
• 配合 TypeScript 定义明确的接口（interface Vehicle），让子类实现时受编译期约束，减少语义漂移。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南