手动实现Promises/A+状态自动流转

本文深入剖析了手动实现符合 Promises/A+ 规范的 Promise 所需的核心要点：强调 executor 必须同步执行、状态不可逆且仅能单向流转、then 方法必须返回新 Promise 并正确调度微任务、严格处理 thenable 的递归展开，以及 resolve/reject 的幂等性保障；这些看似细微的约束实则环环相扣，稍有偏差就会导致链式调用断裂、状态错乱或测试失败——手写 Promise 不是简单的异步封装，而是一场对规范细节的精密工程实践。

Promise 构造函数里必须同步执行 executor

这是 Promises/A+ 最容易被忽略的硬性要求：传入 new Promise(executor) 的 executor 函数，必须**立即、同步调用**，不能 defer、不能 setTimeout、不能 nextTick。否则后续所有状态流转（pending → fulfilled/rejected）都会错位，导致 then 链无法按预期收集回调。

常见错误是把 executor 包在 setTimeout(() => { ... }, 0) 里“模拟异步”，这直接违反规范，测试套件（如 promises-aplus-tests）会立刻报 Test failed: promise created in non-pending state。

• 正确做法：在构造函数内部直接 executor(resolve, reject)
• resolve/reject 必须是函数，且只能调用一次（多次调用应静默忽略）
• executor 抛出异常时，等价于调用 reject(e)，需 try/catch 包裹

then 方法必须返回新 Promise，且支持链式调用

then 不是修改原 Promise，而是返回一个全新的 Promise 实例——这是自动状态流转的核心机制。如果返回的是普通值（比如数字、字符串），新 Promise 状态为 fulfilled；如果返回的是另一个 Promise（或 thenable），新 Promise 状态要**跟随它**（即“穿透”）。

实现上关键点在于：无论当前 Promise 处于 pending、fulfilled 还是 rejected，then 都必须返回 Promise，并把传入的 onFulfilled/onRejected 回调存入对应队列（或立即执行）。注意：不能在 then 内部直接 resolve 当前 Promise，那会破坏链式结构。

• pending 状态：将回调推入 onFulfilledQueue / onRejectedQueue
• fulfilled 状态：用微任务（如 queueMicrotask 或 Promise.resolve().then）延迟执行 onFulfilled(value)
• rejected 状态：同理，用微任务执行 onRejected(reason)
• 返回的新 Promise 的 resolve/reject 必须由执行结果决定，不是由原 Promise 的状态决定

状态只能从 pending → fulfilled 或 pending → rejected，不可逆

Promise 的 state 字段一旦从 "pending" 变为 "fulfilled" 或 "rejected"，就再也不能更改。这是自动流转不混乱的前提。很多手写库在这里出 bug：比如 resolve 后又调用了 reject，或者在不同分支重复 resolve。

典型表现是测试时出现 TypeError: Cannot resolve a resolved promise 类似错误（虽然规范没强制抛错，但必须静默忽略后续调用）。

• 建议用闭包变量 state + value / reason 存储，而非 this.state
• resolve 和 reject 函数开头加守卫：if (state !== "pending") return
• 不要在 resolve/reject 内部再调用对方，也不要在 executor 外部暴露 resolve/reject 引用

处理 thenable 对象时必须遵守“可递归展开”规则

当 resolve 的参数是一个 thenable（即有 .then 方法的对象），Promise/A+ 要求你**尝试调用它的 .then**，并根据其执行结果决定新 Promise 的状态。这不是可选项，是必须递归展开的逻辑。

错误做法是直接把 thenable 当作普通值 resolve，这样会导致 thenable 的异步行为被跳过，链式调用中断。正确做法是用 try/catch 安全调用 thenable.then，并传入自己的 resolve/reject —— 这就是“同构”和“信任传递”的本质。

• 先判断 val !== null && typeof val === "object" || typeof val === "function"
• 再取 then = val.then，确认是函数才进入 thenable 分支
• 调用 then.call(val, resolve, reject)，并确保只调用一次
• 如果调用过程抛错，立即 reject(e)

最难缠的其实是微任务调度时机和 thenable 的嵌套深度：resolve 一个带 then 的对象，它内部 resolve 的又是个 thenable……这种层层穿透必须靠递归+微任务保证不爆栈也不丢任务。写到这儿，基本就不是“手写”而是“重造轮子”了。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~