原型继承是否适合取决于语义关系（“是”而非“有”）、运行时状态隔离需求、父类是否支持继承及继承链可维护性；仅当满足类型归属、无状态共享、明确子类化设计且深度≤2层时才适用，否则应优先选用组合。
判断原型继承是否适合当前业务需求，关键不是看它“能不能用”，而是看它“该不该用”——核心在于语义关系、运行时要求和长期可维护性是否匹配。
看业务关系是不是“一种”而非“有一个”
原型继承表达的是类型归属关系，即“A 是 B 的一种”。如果业务模型天然满足这个逻辑，且需要统一处理、多态调用，才值得考虑。
- ✅ 合适：Customer 和 VIPCustomer 都是 User 的具体类型，系统需统一调用 .getProfile() 或 .isEligibleForDiscount()，且 VIPCustomer 必须能被当作 User 安全替换
- ❌ 不合适：OrderService “用到了” PaymentGateway，但它不是 PaymentGateway 的一种；强行继承会导致类型语义混乱、API 泄露（比如暴露 gateway.connect() 给订单服务）
- ⚠️ 警惕混淆：“User 有头像”是组合，“User 是 Person”才是继承候选；把属性拥有关系误作类型继承，会把封装细节变成强制契约
看是否需要实例状态隔离与运行时替换
原型继承（尤其是 Object.create 或 class extends）在实例创建时就固化了行为来源。如果业务要求灵活切换实现或独立维护状态，它往往力不从心。
- ✅ 合适：配置对象分层（devConfig → stagingConfig → prodConfig），所有层级只读、无状态、不修改共享字段
- ❌ 不合适：多个订单实例共享同一个缓存策略对象，但每个订单应有独立的重试计数器或超时设置；原型链上的引用类型（如 { items: [] }）会被所有实例共用，导致数据污染
- ✅ 替代更优：支付模块需在测试中注入 MockProcessor、生产中切换 AlipayProcessor → 必须用组合 + 接口抽象，而非继承
看父类是否真正设计为可继承
不是所有类都适合作为父类。强行继承未开放设计的类，容易踩坑。
- ✅ 可继承特征：有明确文档说明“支持子类化”，提供 protected 钩子（如 onInit、beforeSave），构造函数接受参数并做合理校验，内部状态通过私有字段 + getter/setter 封装
- ❌ 危险信号：父类字段 public 或默认访问、构造函数副作用强（如自动发起网络请求）、依赖隐式初始化顺序（如必须先调 init() 才能用其他方法）
- ⚠️ 经典反例：把工具类 Utils 或聚合型 Service（如 OrderManager）当基类继承，结果子类被迫承担无关职责，违背单一职责
看未来扩展是否承受得起继承链膨胀
继承结构越深，修改成本越高。如果业务预期会频繁增加新维度（如按能力拆分 Flyable/Swimmable/Climbable），继承很快会僵化。
- ✅ 合理深度：通常不超过 2 层（如 Animal → Bird → Sparrow），且每层有清晰、稳定、不可再分的“is-a”语义
- ❌ 风险信号：为支持“会游泳但不会飞的鸟”，不得不重构 Bird 抽出 Flyable 接口，再让 Duck 实现它 —— 这说明原始继承设计已失衡，此时组合（Duck 持有 SwimBehavior）更轻量、更安全
- ✅ 更可持续：权限控制用 PermissionService 实例注入，而不是 AdminUser extends User；表格渲染逻辑用 renderRow 函数传入，而不是 BaseTable 继承再重写
