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。
立即学习“Java免费学习笔记（深入）”；
- 用工厂函数或
Object.assign()组合行为模块，比深继承链更可控； - 例如：一个
Logger类需要支持不同输出目标（console、file、network），与其让ConsoleLogger继承Logger并重写log()，不如让Logger接收一个transport对象，由 transport 决定如何输出——这样任意 transport 实现都可替换，且不改变Logger的调用契约。
用类型提示和运行时校验辅助保障
虽然 JS 是动态语言，但可通过约定和轻量检查提升 LSP 可靠性：
- 在关键方法入口做参数类型/范围校验（如
decelerate()不允许速度低于 0）； - 对返回值做基本断言（如
state()总是返回预设字符串之一）； - 配合 TypeScript 定义明确的接口（
interface Vehicle），让子类实现时受编译期约束，减少语义漂移。
