先抛一个核心观点：使用 Object.setPrototypeOf 来扩展工厂模式，本质上就是在对象创建之后，动态调整它的原型链，让这个实例“继承”一套新的行为组合。它能够实现运行时按需绑定，无需在构造之初就把构造函数固定死。灵活性的确很高，但原型链污染、性能开销这些潜在问题，也需要充分了解。

为什么不用 class 或普通工厂函数？

传统工厂函数返回新对象，行为依赖复制属性或闭包注入，很难利用原型的复用机制。而 class 方式需要提前定义继承关系，当组合变化较多时，类结构会迅速膨胀。 而 Object.setPrototypeOf 提供了这种自由度： - 按需为不同对象挂载不同行为组合——例如为某个订单临时添加“可退款”或“物流追踪”的能力 - 避免为每一种组合单独定义子类 - 运行时决定原型指向，特别适合配置驱动或插件化场景

基础实现：带行为扩展的工厂

举例来说，假设有一个订单工厂，需要根据订单类型动态挂载不同的能力： ```ja vascript const refundable = { refund() { console.log(`Refunding order #${this.id}`); } }; const trackable = { track() { console.log(`Tracking order #${this.id}`); } }; function createOrder(id, type) { const order = { id, createdAt: new Date() }; if (type === 'premium') { Object.setPrototypeOf(order, { ...refundable, ...trackable }); } else if (type === 'basic') { Object.setPrototypeOf(order, trackable); } return order; } const premiumOrder = createOrder('1001', 'premium'); premiumOrder.refund(); // ✅ premiumOrder.track(); // ✅ ```

注意事项与替代建议

Object.setPrototypeOf 是一个开销较大的操作，它会破坏 V8 的内联缓存，导致性能下降。而且被修改原型后的对象，引擎很难再进行优化（例如隐藏类会失效）。更稳妥的做法包括： - 使用 Object.assign 将方法直接复制到实例上——适合轻量场景，只要方法中没有 this 绑定依赖即可 - 采用策略对象加函数调用，替代原型挂载——例如 handlers[type]?.refund?.(order) - 结合 Proxy 拦截方法调用，按需委托到对应的行为模块 - 如果确实需要动态原型，优先使用 Object.create(proto) 创建对象，而不是修改已有对象的原型

小结

Object.setPrototypeOf 扩展工厂产出的对象，本质上是一种“运行时混入”思路。它适用于原型行为差异大、组合多变、且不想让类定义爆炸式增长的场景，确实很方便。但这并不是默认推荐方案——关键是要先评估是否真的需要动态原型，还是可以用更直接、更容易调试的方式达到相同目标。