JavaScript继承易导致强耦合，因子女类直接依赖父类构造逻辑、属性结构及原型方法；推荐用组合替代继承，通过持有实例调用公共接口，配合插件机制与显式委托解耦，限制class继承深度不超过2层。
JavaScript 继承本身容易带来强耦合，因为子类直接依赖父类的构造逻辑、属性结构和原型方法。一旦父类内部改动（比如重命名方法、修改参数顺序、调整私有状态初始化方式），子类就可能出错或行为异常。这不是语法缺陷，而是设计层面的权衡——继承天然强调“is-a”关系，而现实业务中更多需要“has-a”或“uses-a”关系。
用组合替代继承
把复用逻辑从“父子层级”转为“对象协作”。不通过 extends 让子类继承父类，而是让子类持有父类实例作为属性：
- 子类只调用父类的公共方法，不访问其内部字段或私有约定
- 父类变更不影响子类，只要接口契约（方法名、参数、返回值）不变
- 例如：一个 FormValidator 不继承 RuleEngine，而是接收 RuleEngine 实例，在需要时调用 .validate()
用插件（Plugin）机制解耦
插件不修改类本身，也不依赖类的实现细节，只约定一组生命周期钩子（如 init、bindUI、destroy）和公开 API：
- 控件（如 Grid）只暴露 this.on()、this.getData() 等接口
- 插件通过这些接口工作，完全不知道控件内部如何渲染或存储数据
- 新增功能只需写新插件，无需动原有类，也不会覆盖已有方法
避免在原型上直接混入（mixin）未受控的方法
传统 mixin 把方法一股脑挂到 prototype 上，极易引发命名冲突和行为覆盖：
- 多个 mixin 都定义了 render()，后加载的会覆盖前一个
- 子类无法判断某个方法来自哪个 mixin，调试困难
- 更稳妥的做法是显式委托：在子类中手动调用 mixinA.init(this)、mixinB.bind(this)，控制执行时机和上下文
优先使用 class + extends，但限制继承深度
ES6 的 class 语法本身不解决耦合，但它提供了清晰的契约边界：
- 构造函数参数、super() 调用点、static 方法都更明确，便于约束子类行为
- 配合 TypeScript 可进一步标注 protected / private，限制子类对父类内部的访问
- 实践中建议继承链不超过 2 层（A → B → C），更深的复用应转为组合或策略模式
