原型继承扩展性受限：①原型链共享导致引用类型数据污染；②无法自动传递参数给父类构造函数；③子类强耦合父类原型结构，变更易致崩溃；④混入式扩展难管理、易覆盖、无钩子。
JavaScript 中原型继承的扩展性表面看很灵活，实际用起来容易受限。
它确实支持快速挂载方法、动态修改原型、实现轻量级复用，但这些能力背后藏着几个关键瓶颈，直接影响长期维护和功能演进。
原型链共享带来数据污染风险
父类原型上定义的引用类型属性（比如数组、对象），会被所有子类实例共享。
- 一个实例 push 了数组，其他实例看到的也是改过的数组
- 修改
this.config = { timeout: 3000 }，可能意外影响其他实例行为 - 这不是 bug，是原型机制的固有特性，必须靠手动隔离（如在构造函数里重新初始化）来规避
无法传递参数给父类构造逻辑
原型链继承只复制原型上的方法，不调用父类构造函数：
- 子类实例拿不到父类中通过
this.name = name初始化的自有属性 - 想传参？得配合构造函数继承或手动 call，否则只能靠后期补属性，逻辑割裂
子类强耦合父类原型结构
一旦父类原型方法名变更、签名调整或移除，所有继承它的子类立刻失效：
-
Parent.prototype.init()改成Parent.prototype.setup()，子类调用直接报错 - 没有接口约束，也没有编译检查，问题往往上线后才暴露
- 多层继承时，这种脆弱性会指数级放大
混入式扩展难以统一管理
虽然可以用 Object.assign(Sub.prototype, mixin) 添加功能，但：
- 多个混入对象存在同名方法时，后加载的会覆盖前一个，顺序敏感
- 无法追踪某方法究竟来自哪个混入模块，调试困难
- 缺乏生命周期钩子，无法在“添加方法前”或“覆盖时”做校验或日志
原型继承适合简单场景下的快速复用，比如工具类方法共享、UI 组件基础行为封装。但涉及状态管理、多角色组合、可插拔架构时，更推荐组合 + 工厂函数 + 模块化设计，而非强行拉长原型链。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
