怎么说呢，

完整教学体验请参阅：JavaScript：从事件循环到手写 Promise

第一章 · 单线程与事件循环

为什么 JS 是单线程？话说回来，

JS 一开始的目标只是给浏览器写"小动作"——表单校验、显示弹窗、操作 DOM 节点。Brendan Eich 在 1995 年用十天设计这门语言时做了一个影响长远的决定：所有 JS 代码都跑在同一个线程上。

主要原因是 DOM 不是线程安全的。如果两条 JS 线程同时改一个 DOM 节点。浏览器引擎得在每次访问节点时上锁，性能和实现复杂度都吃不消。"单线程"等于把这种竞态从语言层面直接消灭。其实，

后来出现的 Web Worker、SharedArrayBufferService Worker 看起来像"多线程"。但它们都遵守同一条原则：Worker 不能直接访问主线程的 DOM要通信只能 postMessage 把数据"搬过去"。本质上是隔离的多个单线程世界，而不是真正的共享内存多线程。

单线程的代价

只有一个主线程代表着：所有事情都得排队走这一条线。

代价不只是"页面卡"。话说回来，具体说有三层的观点是。

1. 任意一段长任务会阻塞所有交互——点击、滚动、动画、网络回调全得等。
2. 浏览器一帧只有 ~16.7ms。一旦你的 JS 跑超过这个预算，掉帧就发生了。
3. CPU 密集型工作没法在主线程做——加密、压缩、大数据处理都会让页面"假死"。

这段代码做了什么

console.log
const start = Date.now
while - start <3000) {}
console.log

左边的代码用一个 while 循环纯粹忙 3 秒。不过，这 3 秒里主线程被这个 while 死死占住——任何定时器、任何点击事件、任何渲染都得等它结束。

记住这个事实的观点是。JS 单线程的"死"，不是某个 API 设计得不好，而是物理事实。要绕过它，唯一的办法就是——别在主线程上等。

异步的观点是，把"等待"交出去

上一步代码的问题是：主线程亲自在等。这一步代码做了一件根本上不一样的事——它把"等 3 秒"这件事交给了宿主自己立刻返回。

这就是 JS 异步执行的三件套心智模型：

• call stack同步代码在这里跑。栈一空，当前任务就算结束。
• host APIssetTimeoutfetch文件 IO、DOM 事件…，这些"会等"的能力不属于 JS 引擎而是浏览器/Node 提供的。引擎只管把"任务 + 回调"丢给它们。
• task queue宿主完成等待后把回调推进队列。等主线程空闲，事件循环再把它取出来执行。

console.log
setTimeout => {
console.log
},3000)
console.log

setTimeout 在执行那一刻没有让线程睡觉。至于它干的是，

1. JS 引擎把 cb 和 3000ms 这条信息交给宿主。
2. 宿主用自己的定时器机制数 3 秒。
3. 数到 3 秒后宿主把 cb 推到任务队列里。怎么说呢，
4. 主线程跑完所有同步代码。事件循环从队列里取出 cb执行。

至于输出顺序是，start → end → after 3000ms。end 出现在 setTimeout 之前不是因为它"插队"，而是因为 setTimeout 的回调根本没在当前调用栈里跑。

一个常见误解

很多教程把事件循环画成一个"轮询定时器的轮子"。这是错的，老实说，

事件循环的工作不是"看时间到了没"。而是"当前调用栈空了之后从队列里取下一个任务"。它是个节器，不是计时器，计时是宿主的事。

输出顺序的反直觉

console.log
setTimeout => console.log。0)
Promise.resolve.n => console.log)
console.log

把这段代码丢几个写过 JS 的人，有人答 ,有人答 ,。正确答案是,,。

Promise.resolve.n 看起来"立刻 resolve 了"，但 setTimeout 回调跑得早。至于这只能用事实，任务队列不止一条。话说回来，

• 宏任务放setTimeoutsetIntervalI/O 等。
• 微任务放Promise.nqueueMicrotask 等。

对，现在你只需要记住这两条名字。给出它们之间的精确规则——有了"两条队列"这个事实已经机械推出输出：

1. 同步代码跑完 → 打印同步任务。
2. 同步代码结束这一刻，引擎做一次微任务清空 → 打印微任务。
3. 微任务清空后事件循环取下一个宏任务 → 打印宏任务。

第二章 · 宏任务与微任务

两条不可妥协的规则

宏任务和微任务的全部关系，只用两条规则就能清楚：

1. 一次取一个宏任务执行。
2. 每个宏任务跑完。立刻把当前微任务队列清空，才允许取下一个宏任务。

这两条规则解释了所有"输出顺序"。同一时刻丢进去的setTimeout和Promise.resolve.n永远是微任务跑。

把微任务当成"插队任务"

理解微任务最好的隐喻是插队

微任务有两个特性：

• 优先级高于任意宏任务——再急的 setTimeout 也排在 n 之后。
• 可以连环触发——微任务执行过程中再注册的微任务，会被纳入这次清空而不是等下一轮。这代表着写无限递归注册微任务的代码，会让事件循环永远卡在微任务清空阶段。连渲染都做不了——这是一个真实存在的反模式。

主脚本本身就是一个宏任务

这是初学者最容易漏掉的关键事实：

"同步代码跑完。再清空微任务"这个观察，就是规则特例——主脚本是当前正在执行的宏任务，它结束之前注册的所有n 都排在它的微任务尾巴上，主脚本一结束就被立刻清空。

抓住"主脚本是宏任务",接下来那道综合题题机械推出来。

说到综合输出题，机械推导

console.log
setTimeout => {
console.log
Promise.resolve.n => console.log)
},0)
Promise.resolve.n => {
console.log
setTimeout => console.log。0)
})
queueMicrotask => console.log)
console.log

我们现在有了两条规则 + "主脚本是宏任务"这个事实就可以一步一步硬推出A,G,D,F,B,C,E。

第 1 阶段

• 同步打印 A。
• 注册一个 timer：把 B-C 挂到宿主上。
• 注册一个微任务：D 并注册 timer。
• 注册一个微任务：F。
• 同步打印 G。

主脚本结束这一刻。状态是：

• 再看微任务队列，。
• 宏任务队列这方面，。

• 取出 D打印 D。它内部又执行 setTimeout → 宏任务变成。
• 取出 F打印 F。话说回来，
• 微任务队列空。怎么说呢，

• 取出 B打印 B。它内部 Promise.resolve.n → 推进微任务队列。
• 宏任务结束 → 清空微任务 → 打印C。

• 取出 E打印 E。

最终输出这方面。A,G,D,F,B,C,E。

拿这套机械流程去解题

你会发现"输出顺序题"做完之后没有任何一步靠"感觉"或"经验"。只要按的观点是，

去推就对。这套流程看起来啰嗦，但就是 V8 / SpiderMonkey 等引擎里 Event Loop 的真实方式。

Node 的额外角色

浏览器和 Node 共享"宏任务 + 微任务"的双队列，但 Node 在外层套了一个libuv 事件循环多两个 API：process.nextTick 和setImmediate。

不必背 libuv 那六阶段，只需要记住三层优先级：

层级代表 API何时被清空 nextTick 队列process.nextTick每个阶段切换之间，比微任务更优先 微任务队列Promise.nqueueMicrotask每个阶段切换之间 宏任务setTimeout /setImmediate / I/O 等libuv 当前阶段轮到

setImmediate => console.log)
setTimeout => console.log。0)
Promise.resolve.n => console.log)
process.nextTick => console.log)
console.log

本步的输出顺序大致是：

sync ← 主脚本
nextTick ← 比 n 更急的"独立队列"
promise.n ← 普通微任务
setTimeout ← timers 阶段
setImmediate ← check 阶段

浏览器的渲染时机

事件循环不只跑你的 JS，它还要渲染。简化版的浏览器一帧大致是：

取宏任务 → 清空微任务 → requestAnimationFrame 回调 → 样式/布局/绘制 → 进入下一帧

这就解释了几个常见现象：

• 大量微任务循环会让浏览器永远渲染不到——它卡在"清空微任务"这一步出不来。
• requestAnimationFrame 比setTimeout 更准——前者跟着帧节奏走，后者只是计时。
• 在n 里改 DOM 通常很快就能看到——因为微任务清空后紧接着就是渲染。

事件循环这条线索到这里告一段落。我们接下来要切换视角——从"运行时怎么调度异步"切到"应用层怎么写出可维护的异步"，这正是 Promise。

第三章 · 从回调到 Promise 的动机

三个具体痛点

function getUser {
setTimeout => cb,100)
}
function getOrders {
setTimeout => cb),100)
}
function getDetail {
setTimeout => cb。
100)
}
getUser => {
if return console.error
getOrders => {
if return console.error
getDetail => {
if return console.error
console.log
})
})
})

每个写过 Node 的人都见过这种嵌套结构被称为"回调地狱"，但真正的问题不是嵌套丑，那只是表象。说到痛点有三个，

• 结构由 API 决定。而不是由业务复杂度。说起来，
• 错误处理无法复用每一层都写if 业务复杂之后某一层忘了检查。错误就被静吞了，
• 异步函数没有返回值getUser 的结果没法被赋值给变量，同步代码无论努力都没法刻const user = getUser 这种写法。

我们到底需要什么样的对象？

把上面痛点反着看，需求就清晰了。需要一个对象它：

• 代表未来时刻才会有的值——可以现在传递、存储、返回。
• 支持组合——两个对象串起来。老实说，
• 错误能在末端统一处理——而不是每一层写。
• 能向上下传递异常——同步代码里的catch 可以捕获。

满足这四点的对象就是 Promise。它不是凭空设计出来的，而是被这需求逼出来的。

Promise是一台一次性状态机

Promise 的全部，可以画成三态、单向、一次性：

• pending初始态。话说回来，可以转向fulfilled 或rejected但只能转一次。
• fulfilled成功态。带一个值，
• rejected失败态。带一个原因，

两条不可妥协的约束：

1. 状态不可逆——一旦离开 pending，就再回不去了不能在 fulfilled / rejected 之间跳。
2. resolve / reject 只生效一次——重复调用全部静默忽略。

const p = new Promise => {
resolve
resolve
reject)
})
p.n => console.log)

本代码做了一个验证：resolve之后再 resolve 和 reject 都不会生效，最终 n 拿到的

为什么必须这么严格？

这两条约束看起来只是"小心翼翼"，但它们的存在让使用者代码变得简单。如果状态可以反复变，那 n 里的回调可能被同一个 Promise 触发多次使用者就得自己处理"我已经处理过一次了吗？"这种状态——这正是事件监听器的复杂度。话说回来，Promise 通过单次性把这种复杂度从使用者那里走了。

这两条约束，也是后面所有手写代码里 if return 的来源。

为了让你理解更透彻。接下来从 v1 到 v5，我们一行一行把这台状态机翻译成代码。

第四章 · 手写 MyPromise

v1 · 状态机骨架

class MyPromise {
state = 'pending'
value = undefined
reason = undefined
constructor {
const resolve = => {
if return
this.state = 'fulfilled'
this.value = v
}
const reject = => {
if return
this.state = 'rejected'
this.reason = e
}
try {
executor
} catch {
reject
}
}
n {
if onFulfilled
if onRejected
}
}
new MyPromise => res).n => console.log)

这里是手写实现的最小骨架：一个 class。三个字段，resolve 和 reject 都有 if 守卫——这就是上面的约束。按理说，再看注意细节，resolve 和 reject 不是 MyPromise 方法。而是构造函数里的闭包，n 只会同步执行。

v1 暴露的问题

把构造函数里 executor 改成异步，比如：

new MyPromise => setTimeout => res。100)).n => console.log)

n注册的那刻，状态还是 pending。v1 的 n 什么都不做——回调被丢掉了。100ms后 resolve 触发，也没人通知。从办法来看，在 pending 阶段把 n 传来的回调存起来。

v2 · 把 pending 阶段的回调存起来

class MyPromise {
state = 'pending'
value = undefined
reason = undefined
onFulfilledCbs =
onRejectedCbs =
constructor {
const resolve = => {
if return
this.state = 'fulfilled'
this.value = v
this.onFulfilledCbs.forEach => cb)
}
const reject = => {
if return
this.state = 'rejected'
this.reason = e
this.onRejectedCbs.forEach => cb)
}
try {
executor
} catch {
reject
}
}
n {
if onFulfilled
else if onRejected
else {
if this.onFulfilledCbs.push
if this.onRejectedCbs.push
}
}
}
new MyPromise => setTimeout => res。100)).n => console.log)

v2 在两个地方动了刀：新增数组 onFulfilledCbs/onRejectedCbs，作为等候队列。n 在 pending 时把回调入队；resolve/reject 触发时遍历队列依次通知。这是经典的订阅者模式：Promise 是发布者，每次 n 都是注册一个订阅者。为什么是数组而不是单个，因为同一个 Promise 可以被 n 多次。

v2 还有的问题

v2 已经能正确处理 executor 里异步 resolve 的情况了。但仔细看 n：当状态已经是 fulfilled 时它同步调用 onFulfilled。说白了我们的 MyPromise 出现了一种糟糕的双面性：executor 里同步 resolve → n 同步执行；executor 里异步 resolve → n 异步执行。不过，同一个 API、一样的调用，行为却随上下文变化。这种 API 在社区叫 Zalgo。

v3 · 让 n 永远异步

class MyPromise {
state = 'pending'
value = undefined
reason = undefined
onFulfilledCbs =
onRejectedCbs =
constructor {
const resolve = => {
if return
this.state = 'fulfilled'
this.value = v
this.onFulfilledCbs.forEach => cb)
}
const reject = => {
if return
this.state = 'rejected'
this.reason = e
this.onRejectedCbs.forEach => cb)
}
try {
executor
} catch {
reject
}
}
n {
const runFulfilled = => queueMicrotask => onFulfilled?.)
const runRejected = => queueMicrotask => onRejected?.)
if runFulfilled
else if runRejected
else {
this.onFulfilledCbs.push
this.onRejectedCbs.push
}
}
}
console.log
new MyPromise => r).n => console.log)
console.log

v3 的改动只有一处但分量重：在调用 onFulfilled/onRejected 之前，统用 queueMicrotask 包一层。无论当前状态是 fulfilled/rejected 还是 pending，回调都被推到微任务里执行。话说回来，这一改之后MyPromise 的执行时机和原生 Promise 一致了。

为什么是 queueMicrotask 而 setTimeout？

两个原因这方面，1.语义对齐原生：原生 n 就是微任务。如果我们用 setTimeout，MyPromise.n 会变成宏任务。跟原生在同一段代码混用就会出现微妙的顺序。2.微任务比宏任务快得多：setTimeout 即使在理想情况下也要等 4ms；queueMicrotask 紧接着当前任务就跑。Promise 的主要使用场景是链式异步。这种场景里慢哪怕几毫秒，叠加起来都很观。

v3 的隐藏收益还顺手解决了一个 v4 才会用到的问题：n 里需要在闭包中引用一个还没赋值的 promise2。把回调推迟到微任务里等微任务真正跑起来promise2 已经从 new MyPromise 表达式里赋值出来了。

v4 · 链式调用的本质

class MyPromise {
state = 'pending'
value = undefined
reason = undefined
fcbs =
rcbs =
constructor {
const resolve = => {
if return
this.state = 'fulfilled'
this.value = v
this.fcbs.forEach => cb)
}
const reject = => {
if return
this.state = 'rejected'
this.reason = e
this.rcbs.forEach => cb)
}
try {
executor
} catch {
reject
}
}
n {
const fulfilled = typeof onFulfilled === 'function'?onFulfilled : => v
const rejected = typeof onRejected === 'function'?onRejected : => { throw e }
const promise2 = new MyPromise => {
const runFulfilled = => queueMicrotask => {
try { resolve) } catch { reject }
})
const runRejected = => queueMicrotask => {
try { resolve) } catch { reject }
})
if runFulfilled
else if runRejected
else {
this.fcbs.push
this.rcbs.push
}
})
return promise2
}
}
new MyPromise => r)
.n => v)
.n => v)
.n
.n => console.log)

链式调用 p.n.n 之所以成立。是因为 n 返回一个新的 Promise——我们叫 promise2——它的状态由 a 的执行决定：如果 a 返回一个 x，promise2 resolve；如果 a 抛错，promise2 reject。v4 的主要是把 n 的返回值改成 new Promise => { ... })，并把 try { resolve) } catch { reject } 这段逻辑嵌进去。

值穿透/错误穿透

了一个容易忽略的情况：n 或者只写 n。至于这种情况下，

• 没有 onFulfilled 用默认 => v。把当前值原样传给下游，其实，
• 没有 onRejected 用默认抛出 => { throw e }。让下游继续 reject。

这就是"值穿透/错误穿透"。不过，它让跨过中间没写错误处理的 n，一路落到末端的 catch。怎么说呢，

v4 还差一步

v4 已经能处理 onFulfilled 返回普通值的情况。说起来，但如果它返回的 x 本身是一个 Promise 呢？再看比如，

fetchUser.n => fetchOrders) // 返回值是另一个 Promise

v4 会把这个 Promise 当普通值丢进 resolve 里导致 promise2.value === Promise 对象。下游 n 拿到的不是订单数据，而是个 Promise。这显然不是我们要的——下游等到内层 Promise resolve 出真正的值之后触发。这就是 resolvePromise 要解决的问题。

v5 · resolvePromise · 规范

function resolvePromise {
if {
return reject)
}
if ) {
let called = false
try {
const n = x.n
if {
n.call(
x。=> {
if return
called = true
resolvePromise
},=> {
if return
called = true
reject
},)
} else {
resolve
}
} catch {
if return
called = true
reject
}
return
}
resolve
}

resolvePromise 是整个手写过程里最出错的一段。再看它的工作是，拿到 onFulfilled 返回的 x。根据 x 的形态决定怎么 resolve promise2。Promises/A+ 规范节用了整整一页篇幅描述它，对应到代码就是本步的 resolvePromise 函数。它应对几种情况：

• promise2 === x：必须 reject 一个 TypeError，这是规范要求的。
• x 是另一个 Promise：调用 x.n 这种写法会让 promise2 等待 x。为了防止 promise2 等死，必须加一个 called 标志位。如果 已经 resolve 了就不再操作。
• x 不是对象：直接 resolve。其实，
• x 是基本类型：直接 resolve。话说回来，

这里MyPromise 的主要就完成了。

MyPromise.all = => newPromise => {
const out =
let done = 0
if return resolve
xs.forEach => {
p.n(
=> {
out = v
if resolve
},reject
)
})
})
MyPromise.race = => newPromise => {
xs.forEach => p.n)
})
MyPromise.allSettled = => newPromise => {
const out =
let done = 0
if return resolve
xs.forEach => {
p.n(
=> {
out = { status: 'fulfilled',value: v }
if resolve
}。=> {
out = { status: 'rejected',reason: e }
if resolve
},)
})
})
MyPromise.any = => newPromise => {
const errs =
let failed = 0
if {
return reject)
}
xs.forEach => {
p.n => {
errs = e
if {
reject)
}
})
})
})

第五章 · 静态方法与规范验证

四个常考静态方法

Promise.all / race / allSettled / any 经常出现在面试里其实代码差异小——主要是语义差异。

全部成功 → 任意一个失败 → 立刻 reject 那个 reason第一个 fulfilled 的值第一个 rejected 的 reason全部 settle → 永远不会任意一个成功 → 那个值全部失败 → AggregateError

方法	何时 fulfilled	何时 rejected
all
race
allSettled
any

all 和 any 是镜像关系——一个"任意失败就 reject"、一个"任意成功就 resolve"。race 和 allSettled 处于两个极端——race 抢第一个 settle 的、allSettled 等所有人 settle。

空数组的边界陷阱

每个静态方法对空数组的行为都不一样。面试常考：

AggregateError

调用	结果
Promise.all
Promise.race
Promise.allSettled
Promise.any

如果直接写 if，这个 throw 会逃出 catch。第三方库或实现的 nable 不遵守只一次规则，标志位让 promise2 等锁。

---