用 setPrototypeOf 实现策略热切换可行但需谨慎：需封装无状态策略对象、避免闭包捕获、同步协调切换时机、隔离作用域并复用 prototype；更推荐组合式方案如策略工厂、Proxy 代理或发布订阅。
在实时协作文档系统中，用 setPrototypeOf 实现策略热切换是可行的，但需谨慎——它不是通用方案，而是特定场景下的底层控制手段。核心思路是：将文档协作行为（如冲突解决、变更广播、本地暂存）封装为可替换的策略对象，再通过动态修改实例的原型链，让运行时对象即时继承新策略的行为。这要求策略设计为纯方法集合、无状态或显式状态托管，且所有调用路径都依赖原型链查找（而非硬编码引用）。
策略对象必须是“原型友好”的
热切换的前提是策略本身不依赖闭包或构造时绑定的上下文。推荐把策略定义为 plain object 或 class 的静态方法集，并确保所有方法只访问 this 上的公开属性（如 this.docId、this.channel），不捕获外部变量。
- ✅ 正确示例：
const mergeStrategy = { resolveConflict(deltaA, deltaB) { return deltaA.version > deltaB.version ? deltaA : deltaB; } }; - ❌ 错误示例：
const createStrategy = (timeout) => ({ sync: () => setTimeout(..., timeout) });—— 闭包捕获了timeout，无法通过原型切换更新。 - 建议把配置项（如超时、重试次数）抽离为独立状态对象，由主实例持有并传入策略方法，而非嵌入策略内部。
切换前需确保行为一致性
直接调用 Object.setPrototypeOf(instance, newProto) 会立即生效，但可能引发竞态：若当前正执行旧策略中的异步回调（如 WebSocket 收到消息后调用 oldProto.applyDelta），而此时原型已被替换，该回调仍沿用旧方法；后续新调用才走新策略。因此必须同步协调。
- 暂停所有输入源（如编辑器事件监听、WebSocket 消息接收），等待当前任务队列清空（可用
await Promise.resolve()）。 - 确保策略方法不持有未完成的 Promise 引用，或在切换前主动 cancel/abort 相关操作（例如 abortController.signal）。
- 切换后触发一次轻量级校验（如
instance.testStrategy()），确认关键方法已就位且能访问必要上下文。
避免原型污染与内存泄漏
setPrototypeOf 是高危操作，尤其在多人协作共享对象（如全局文档模型）时，错误切换可能影响其他模块。务必隔离作用域。
- 不要对跨模块共享的根对象（如
window.DocEngine）直接改原型；应仅作用于具体文档实例（docInstance）。 - 每次切换前保存旧原型（
oldProto = Object.getPrototypeOf(instance)），便于回滚或调试。 - 策略 prototype 对象应复用而非重复创建（例如缓存
STRATEGIES.OFFLINE_FIRST），否则频繁生成新 prototype 可能触发 V8 隐式类去优化（deopt）。
更安全的替代路径值得优先考虑
虽然 setPrototypeOf 能实现热切换，但现代协作系统通常更适合组合式策略管理：
- 用策略工厂 + 依赖注入：实例持有一个
strategyRef弱引用，所有方法调用都经this.strategyRef.current.xxx()中转，切换只需赋值strategyRef.current = newStrategy。 - 基于 Proxy 封装策略代理：拦截对策略方法的访问，动态转发到当前激活的策略对象，语义更清晰、无原型副作用。
- 结合发布订阅：当策略变更时，发布
strategy:changed事件，各模块自行响应（如重置本地 buffer、刷新 UI 状态），解耦更强。
