组合比继承更适合作为Class语法下主流的代码复用方式，因其松耦合、易测试、支持运行时替换；继承仅适用于语义清晰的“是一个”关系，且需满足里氏替换原则、控制继承深度；现代框架普遍采用组合优先策略。
组合比继承更适合作为 Class 语法下主流的代码复用方式。它更松耦合、更易测试、更利于运行时替换行为，而继承容易导致隐式依赖和脆弱的类层级。
继承适用于“是一个”关系的场景
当子类确实是父类的一种具体类型时，继承才自然成立。比如 AdminUser extends User，表示管理员用户是一种用户；Dog extends Animal，表示狗是一种动物。这种语义清晰、不可变的分类关系，是继承的合理使用前提。
如果只是为了复用方法而强行建立“is-a”关系（例如让 ReportGenerator extends DatabaseConnection），就会破坏模型一致性，后续维护成本陡增。
- 子类必须真正能替代父类（满足里氏替换原则）
- 父类应设计为可被安全继承（如提供 protected 钩子、避免 final 方法过度限制）
- 继承深度建议不超过两层，否则调试和理解成本明显上升
组合通过成员对象实现功能拼装
组合体现的是“有一个”关系，即一个类持有另一个类的实例，并通过委托调用其能力。例如：Car 类包含 Engine 实例，不是说“汽车是一种发动机”，而是“汽车有发动机”。
这种方式把功能拆解成独立单元，每个单元职责单一、可单独测试、可随时替换——比如把 MockEngine 注入到 Car 中做单元测试，或在运行时切换不同功率的 TurboEngine。
- 组合对象通常通过构造函数或 setter 注入，便于控制生命周期
- 对外暴露的接口由当前类统一定义，隐藏内部组件细节
- 支持多实例复用（如一个类同时持有 Logger 和 Validator）
继承的隐性风险常被低估
继承会让子类无意中依赖父类的实现细节。比如父类某个 public 方法内部调用了另一个 protected 方法，子类重写了后者，却没意识到它被父类其他逻辑间接调用——结果行为异常，且难以追溯。
更典型的问题是：父类增加一个参数、改一个访问修饰符、甚至只是调整初始化顺序，都可能让子类编译失败或运行出错。这种强耦合违背封装原则，也削弱了可维护性。
- 子类无法绕过父类构造逻辑，初始化约束更刚性
- 无法在不修改类定义的前提下更换父类行为
- 多继承（如 Python）或 mixin 使用不当，易引发方法解析顺序（MRO）混乱
现代 Class 设计更倾向组合优先
TypeScript 的 implements + 组合、React 的自定义 Hook 封装逻辑、Vue 的 Composition API，本质上都在推动“行为复用”脱离“类继承树”。它们共同指向一个实践共识：把可变的部分抽成独立对象，再按需组装。
即使使用继承，也推荐配合组合——比如父类只定义骨架和契约，具体策略由组合进来的对象实现。这样既保留了类型语义，又把变化点隔离出来。
- 用 interface 或 abstract class 定义能力契约，而非靠继承传递实现
- 工具类、配置类、服务类，几乎从不作为父类被继承，而是被组合
- 框架扩展点（如 Express 中间件、Webpack Plugin）均基于函数或对象注入，非继承
