解决工作流引擎多层级嵌套对象原型置换导致的状态失控

在工作流引擎中，当多层级嵌套对象的原型被置换后，问题的核心并非“状态失控”，而是实例与调度逻辑之间的引用链被彻底切断。对象的方法虽然仍可调用，但内部的状态绑定、上下文指向、微任务注册路径以及时序控制网关均无法正常响应。修复的关键不在于回滚原型，而在于重建可信执行上下文——这是整个恢复过程的基础逻辑。

确认置换：三个检查点

如何判断嵌套对象（例如 loopNode、iterator、contextWrapper）的构造器原型确实被篡改？可从三个维度入手：

• 使用 Object.getPrototypeOf(obj) 检查原型指向——正常应指向原始构造器原型，而非 Object.prototype 或一个空对象。
• 查看 constructor.name 与 Symbol.toStringTag——若返回 "Object" 或 undefined，说明构造器已被覆盖或丢失。
• 访问私有状态字段（如 _scheduler、_abortSignal、_queue）——若值为 undefined 或 null，则调度入口已被剥离。

立即止血：绕过异常实例，不依赖原型查找

对于已经产生但行为异常的嵌套对象，切勿再调用其 .next()、.run() 等原型方法。正确做法是：

• 使用独立封装的新实例接管流程，原对象仅作为状态快照的来源。
• 将原对象的状态提取出来（例如通过 JSON.stringify(obj.state) 或深拷贝关键字段），作为新实例的初始化输入。
• 所有后续节点调度改用 queueMicrotask(() => { ... }) 显式入队，绕过已被污染的 Promise.then 或自定义微任务注册逻辑。

恢复可控性：组合替代继承，闭包固化上下文

节流、中断、重试等能力应从原型方法中抽离，封装为纯函数（例如 throttle(task, ms)、withAbort(task, signal)），在节点初始化时注入，而非运行时沿原型链动态查找。构造函数中利用闭包捕获调度器，是一种有效的固化手段：

class WorkflowNode {
  constructor(config) {
    const scheduler = createScheduler(config); // 闭包持有
    this.execute = () => scheduler.tick();     // 绑定到实例，不查 prototype
  }
}

对于第三方插件或 SDK 创建的嵌套对象，强制使用 Object.freeze() 锁定其原型，并通过 Proxy 拦截对 prototype 的非法赋值操作。

长期防御：启动即冻结，运行即隔离

防线应前置到应用加载早期——例如在入口文件的第一行就执行：

Object.freeze(Array.prototype);
Object.freeze(Promise.prototype);
Object.freeze(WorkflowIterator.prototype);

对不可信代码（如用户上传的 JS 片段、低权限 SDK），启用 iframe 沙箱或 Web Worker 隔离，禁止其访问主工作流的原型链。在 CI/CD 流程中加入 ESLint 规则 no-extend-native，并结合 TypeScript 的 noImplicitAny 与 strictBindCallApply 来捕获潜在的原型篡改调用。

不复杂，但容易被忽略。