原生 Promise 无法控制微任务调度，因其 then/catch 回调由运行时自动推入微任务队列且不可拦截、延迟或取消；必须手动维护可干预的任务队列，用 queueMicrotask() 显式投递，并通过 flush() 统一调度 pendingTasks，同时快照需重置 state 并清空 pendingTasks 以确保状态与任务严格对齐。
为什么不能直接用原生 Promise 实现微任务调度控制
原生 Promise 的 then/catch 回调一定被推入微任务队列（由浏览器或 Node.js 运行时隐式管理），你无法拦截、延迟、批量合并或取消这些微任务。一旦 resolve() 被调用，后续链式回调的执行时机就脱离你的掌控——这对需要精确调度（比如动画帧对齐、节流式状态更新）或快照回滚的场景是硬伤。
所以必须绕过原生 Promise 构造器的自动调度机制，自己维护一个可干预的任务队列。
- 不调用
Promise.resolve()或new Promise()来触发微任务 - 用
queueMicrotask()手动投递，但只在你确认要执行时才调用 - 所有状态变更（
pending → fulfilled等）必须显式记录到快照结构中
如何设计可快照的状态机与任务缓冲区
核心不是“模拟 Promise”，而是“记录状态 + 延迟执行”。你需要两个关键结构：state（当前值与状态）和 pendingTasks（待调度的回调列表）。
state 必须包含 status: 'pending' | 'fulfilled' | 'rejected'、value、reason，且每次变更都应生成不可变副本（避免快照污染）；pendingTasks 是个数组，每项是 { onFulfilled, onRejected, resolve, reject }，对应一次 then 调用的上下文。
- 调用
then(onFulfilled)时不立即注册微任务，只 push 到pendingTasks -
resolve(value)不触发执行，只更新state并标记“可调度” - 快照只需深拷贝
state和pendingTasks.length（内容不可变，存引用即可）
如何安全触发微任务并支持手动 flush
真正的调度入口只有一个：你主动调用的 flush() 方法。它决定何时把 pendingTasks 中的回调真正推入微任务队列。
注意：不能在 flush() 内直接遍历执行回调（会变成同步，失去微任务语义），也不能重复调用 queueMicrotask() 导致无限循环（比如回调里又调 then）。正确做法是清空当前 pendingTasks，再逐个包装后投递：
flush() {
const tasks = this.pendingTasks;
this.pendingTasks = [];
for (const task of tasks) {
queueMicrotask(() => {
// 在这里执行 onFulfilled/onRejected，并捕获异常
// 异常需重新 reject 下游，但不立即 flush，留待下次调用
});
}
}
- 必须清空
pendingTasks再投递，否则嵌套then可能漏掉新任务 - 投递前不检查
state.status—— 因为flush本就是“按当前状态执行所有积压回调” - 若在微任务中抛错，不要吞掉，应存入
state.reason并触发下游onRejected
快照还原时为何不能简单赋值 state
还原快照不是 this.state = snapshot.state 就完事。因为 pendingTasks 中可能已有回调绑定了旧闭包（比如引用了上一帧的局部变量），而快照只保存了状态值，没保存执行上下文。
所以快照还原必须是“状态重置 + 任务清空 + 强制阻断”三步：
- 用快照的
state替换当前state（浅拷贝即可，value/reason 是值类型或冻结对象） - 将
pendingTasks置为空数组 —— 已注册但未 flush 的回调全部丢弃 - 确保之后第一次
flush()只基于新状态执行，不混入旧任务
这正是手动容器比原生 Promise 更可控的地方：你掌握着“哪些任务该活、哪些该死”的开关。复杂点在于，快照粒度必须和业务语义对齐——比如一次用户操作生成一个快照，而不是每一行 JS 都拍。
