异步控制流一直是个让人又爱又恨的话题。很多同学每天都在写 .n 和 async/await但只要遇到复杂的异步执行顺序题，大脑就会瞬间宕机。不过，

作为计算机专业的学生，我们不妨换个视角：不要把 Promise 当成某种神奇的魔法 API。而是把它看作一个经典的“状态机”与“发布-订阅模式”的结合体。

今天我们将通过四段一步步来的代码。重走一遍前端异步演进的历史，最终亲手撸出一个 Promise 的主要源码。

阶段一这方面，同步与异步的时空错位

一切的痛点。都源于 JavaScript 的单线程与事件循环机制。看下面这段最基础的代码：

let a = null;// 同步任务
setTimeout => { // 异步任务
a = 42;},1000)，不过，console.log;// 输出结果：

发生了什么？ JS 引擎是一个按部就班的单线程工人。说起来，当它遇到 setTimeout 时并不会在这里傻等 1 秒。而是把这个计时任务“外包”给了宿主环境，接下来头也不回地继续往下执行 console.log。此时 1 秒还没过去，a 当然还是 null。等到 1 秒后外包团队把回调函数塞进任务队列，JS 引擎才会在空闲时去执行它。

痛点： 我们无法在主线程里按照从上到下的顺序，直接拿到异步操作的结果。其实，

阶段二的观点是，原始时代的妥协 —— 强耦合回调

为了在获取到数据后立刻使用它。早期开发者采用了最直白的方式：既然我不知道你什么时候完事，那我就把接下来要干的活直接塞进你的回调里。

let a = null;不过，function fetchUserData {
// 模拟向后端请求数据。耗时 1s
setTimeout => {
a = "data from backend";renderData，// 拿到数据后立刻手动调用接下来操作
},1000);}
function renderData {
// 将得到的数据渲染在页面上
console.log;}
fetchUserData;

这有什么问题？

• 强耦合fetchUserData的内部硬编码了对 renderData的调用。
• 再看性差。需求变更时需要去改底层网络请求代码，就像一个过度操心的包工头，买完砖头还要亲自盯着木匠干活。

至于阶段三。现代破局方案 —— 状态机与链式控制流

为了实现解耦让买砖头的只管买砖，干活的只管干活，Promise 横空出世。我们用一个经典的“获取使用者信息 → 获取订单”的业务线来生动演示：

// 任务 A：获取使用者
function fetchUser {
// . 内部初始化一个状态 state = pending
return new Promise => {
setTimeout => {
console.log;resolve，// . 任务完成，拧动钥匙，把 uid 传出去
},1000);})，}
// 任务 B：获取订单
function fetchOrders {
return new Promise => {
setTimeout => {
console.log;resolve，},1000);
})，说起来，}
// . 外部的控制流
fetchUser
.n => {
// . n 裏面的回调函数。会被悄悄存进 Promise 内部的队列里
return fetchOrders;// 返回新的 Promise，开启接下来
})
.n => {
console.log;})
.catch => {
console.error;})，

控制流解析

1. new Promise 瞬间返回一个状态为 pending 的对象。这相当于给出了一个“未来会兑现的凭证”。
2. 当我们调用 .n 时此时数据还没回来里面的回调函数并不会立即执行，而是被悄悄推入了 Promise 内部的订阅队列里.
3. N 秒后执行 resolve.
4. resolve` 的执行。将 Promise 的内部状态不可逆地从 pending 为 fulfilled并立刻唤醒当初存起来的函数，把对应值塞给它。

DONE：

• No knowledge of who is waiting: fetchUser 只负责在结束时大喊一声 alert )),完全不关心后面是谁消费结果。
• No callback hell: 每一步都返回新的 

阶段四的观点是。扒开源码看本质 —— 手写状态机

Dive into core: 既然 Promise 就是个状态机 + 数组，可以用几行原生 JS 把它捏出来。下面代码展示了最关键的三个概念：

• Status ： "pending","resolved"。"rejected"
• Auction queue ：  存放所有通过 .n 注册进去的函数，实现发布‑订阅模型。
• The trigger ：  改变状态并一次性遍历执行对应队列里的回调。

function MyPromise {
// . 初始化状态为 pending
this.state = "pending";

// . 用数组保存 n 注册进去的回调 this.callbacks =;

// . 定义 resolve 方法——状态机主要：不可逆性，只能从 pending 转一次 const resolve = => { if { this.state = "resolved";this.callbacks.forEach);} }，

const reject = => { if { this.state = "rejected";// 简化处理：实际实现会有 rejectCallbacks 队列，这里略过 } };话说回来，

// . 同步执行传入的 executor。让它拥有 resolve / reject 能力 try { executor;} catch { reject;} }

// 极简版 n —— 支持基本链式调用 MyPromise.prototype.n = function { if { this.callbacks.push;// 暂存回调 } else if { onFulfilled;// 已经 resolved 时直接执行 } return this;// 为链式调用提供返回值 };其实，

Dawn of insight： 看懂这段手写代码。你就彻底破除了 Promise 的神秘感。它根本没有任何超越原生 JS 的底层魔法，只是巧妙地利用了*面向对象* 思想。把「异步操作的状态」)和「未来需要执行的代码」封装在同一个实例里。

• . 当你调用 .n 时就是往数组里 push 一个函数；
• . 当你调用 resolve 时就是把数组里的函数拿出来 forEach 遍历一次。

从杂乱无章 的硬编码回调。到井然有序 的状态机链式调用，Promise 的演进完美体现了计算机科学中“高内聚、低耦合”的设计哲学。掌握内部订阅流转机制以后无论面对多复杂 的异步调度算法。都能在脑海 中清晰画出其 执行栈 与 微任务队列，从而轻松定位、调整、 业务逻辑。