继承并非总是最佳选择，它虽能复用代码并表达类型关系，但易导致耦合、脆弱性和设计僵化；真正关键的是审慎判断“要不要继承”及是否存在更轻量的替代方案。
继承不是总是最好的选择。它在某些场景下确实能复用代码、表达类型关系，但容易带来耦合、脆弱性和设计僵化。真正影响扩展性的，往往不是“能不能继承”，而是“要不要继承”以及“有没有更轻量的替代方案”。
继承的典型问题：看似方便，实则埋雷
JavaScript 中常见的继承实现（如组合继承、寄生组合继承）虽能解决属性隔离与方法复用的平衡，但仍存在几个关键局限：
- 构造函数调用冗余：组合继承中父类构造函数被调用两次，一次用于设置子类原型，一次用于初始化实例，造成不必要的属性初始化开销；
- 原型链污染风险：若父类原型上挂载了可变对象（如数组、普通对象），所有子类实例共享该引用，一个实例修改会影响其他实例；
- 单向强依赖：子类必须知道并依赖父类的内部结构和生命周期，一旦父类调整（比如重命名方法、改变参数顺序），多个子类可能同时报错；
- 难以多角色复用：一个类本应专注做一件事，但为复用某功能而继承整个父类，相当于把“获取数据”“校验规则”“日志上报”全打包进一个基类，违背单一职责。
比继承更灵活的扩展方式：组合与委托
当目标是增强能力而非定义“是什么”，组合（Composition）通常比继承更自然、更可控：
-
按需装配功能：比如报表服务不需要“成为”一个数据获取器，只需持有
ProductFetcher实例，在需要时调用fetch()； - 运行时可替换：测试时可用 mock fetcher，线上可切换不同策略（缓存版/实时版/API 版），无需改动主类结构；
-
避免层级爆炸：不用为了支持“带权限校验的报表服务”再建一层
SecureReportService extends ReportService，而是直接组合AuthChecker； - 天然支持多行为混入：一个类可以同时组合日志、重试、节流等模块，而继承只允许一条主线。
什么时候可以考虑继承？明确边界再动手
继承仍有其合理位置，但前提清晰：
-
语义上确属“is-a”关系：比如
AdminUser是一种User，具备相同身份契约（登录、登出、权限检查接口），且客户端常以父类类型使用子类（即接口继承）； -
框架强制要求：React 类组件、Vue 2 的
extends Vue、或某些 SDK 要求继承特定基类才能接入生命周期钩子； -
极简复用且无副作用：仅复用少量不可变配置或工具方法，且父类无状态、无副作用构造逻辑（如纯工具基类
EventEmitter）。
现代实践建议：优先用 class + 组合，谨慎用 extends
ES6 class 和 extends 是语法糖，底层仍是寄生组合继承——它让写法更整洁，但不改变继承的本质约束。日常开发中更推荐：
- 用
class定义清晰契约（如接口、抽象方法），但具体实现交由组合对象完成； - 把通用逻辑拆成独立函数或类（如
ApiRequester、FormValidator），通过构造参数或 setter 注入； - 对已有类扩展行为，优先用装饰器（如
@withLogging）、高阶函数或代理（Proxy）包装，而非继承； - 团队协作时，在文档或类型定义（TypeScript）中标明“此基类仅供框架集成，业务类请勿继承”，防止误用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
