Promise核心状态变化过程实现原理

想要深入掌握 Promise 的运行机制，就必须先剖析其底层的状态机模型。核心原理其实就六个字：单向、不可逆、不可回退。理解 Promise 的关键，全在于这套状态变化的规则体系。

每一个 Promise 实例从创建的那一刻起，就处于三种状态之一：pending（待定）、fulfilled（已成功）、rejected（已失败）。状态的转换由执行器（executor）中显式调用的 resolve 或 reject 函数触发。一旦状态确定，便永久锁定，无法再更改。

状态只有三种，且严格单向转移

每个 Promise 实例在任何时刻都只属于以下一种状态：

• pending：初始阶段，既未成功也未失败，允许状态转变
• fulfilled：成功态，由 resolve(value) 触发，之后状态固化，不可再变
• rejected：失败态，由 reject(reason) 触发，同样永久锁定

状态之间的变更路径只有两条：pending → fulfilled 或 pending → rejected。一旦进入已完成或已拒绝状态，后续再调用 resolve 或 reject 都会被忽略。这就是“单向不可逆”的直观体现。

状态变更的原子性保障

每次调用 resolve 或 reject 时，内部会先检查当前状态是否仍为 pending：

• 如果不是 pending，直接返回，不执行任何操作
• 如果是 pending，才更新 this.state，并保存 this.value 或 this.reason

这种“先判断后修改”的原子性逻辑，确保了状态变更不会被重复或覆盖，竞态条件自然不复存在。换句话说，最先调用的 resolve 或 reject 决定了最终结果，后续调用都只能作为旁观者。

状态改变后触发对应回调

Promise 内部维护了两个回调队列：onFulfilledCallbacks 和 onRejectedCallbacks。当 then 被调用时，这些回调函数会被收集起来，等到状态真正变更后统一执行：

• 状态变为 fulfilled → 遍历并执行所有成功回调，传入 this.value
• 状态变为 rejected → 遍历并执行所有失败回调，传入 this.reason

这里有一个关键的实现细节：这些回调通过 queueMicrotask（微任务）进行调度。它们会在当前同步代码执行完毕后、下一个宏任务开始之前被执行。这正是 Promise 实现“异步但不延迟”的底层机制——你注册的回调不会立即执行，但也不会被推迟到遥远的定时器里。

执行器立即运行，状态即刻可控

当 new Promise 时，传入的 executor 函数会同步立即执行。这意味着，resolve 或 reject 的调用时机完全由你掌控：

• 可以立刻 resolve，创建一个已成功的 Promise
• 可以在 setTimeout 后 reject，模拟异步失败场景
• 也可以直接抛出异常，自动触发 reject

这种设计让 Promise 的状态起点非常清晰，整个过程完全可预测。正是基于这套稳固的状态机模型，链式调用和错误冒泡才能顺畅地运行起来。