Lee General2. 写在前面：为什么每个 JS 开发者都该吃透这两个概念
如果你写 JavaScript 写过一段时间，一定遇到过这种画面：明明代码是从上往下写的，执行顺序却完全不按套路出牌；明明 setTimeout 写在前面，后面的 Promise 却先跑完了；明明 await 已经等了一个异步任务，页面还是卡了一下才更新。这些现象背后，全是事件循环和 Promise 在起作用。
很多初学者把 Promise 当成“消除回调地狱的工具”，把事件循环当成“面试八股文”，这样理解其实很可惜。事件循环是 JavaScript 运行时的底层调度机制，Promise 是构建在它之上的异步控制流工具，两者一个是地基，一个是楼层——不理解地基，楼层盖得再漂亮也心里没底。
这篇内容适合三类人：刚学完 JS 基础、准备进阶的初学者；写过一段时间业务代码、想搞清楚异步背后原理的开发者；以及准备面试、想把事件循环和 Promise 讲明白的求职者。我会从底层模型讲起，逐步拆解到实际开发中的应用场景和坑点，你会知道为什么微任务优先于宏任务、为什么 Promise.resolve 包裹的代码总会比 setTimeout 先执行、为什么 await 后面不跟 Promise 也会产生等待效果。
全程没有晦涩的术语堆砌，遇到概念我会用生活化类比来解释，配合可运行的代码示例。看完之后，你至少能独立分析一段复杂异步代码的执行顺序，并且能在真实项目里正确使用 Promise 避免踩坑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
1. 事件循环底层模型：JavaScript 为什么需要“排队机制”
1.1 单线程的宿命与浏览器里的“老板秘书”
JavaScript 是单线程语言，这意味着它只有一个调用栈（Call Stack），同一时间只能执行一段代码。这个设计最初是为了简化 DOM 操作——如果多个线程同时修改同一个节点，浏览器根本不知道听谁的。但单线程带来一个问题：如果某段代码执行时间太长，后面的代码就一直等着，页面就会卡死。
为了解决这个问题，JavaScript 引入了异步机制。但异步任务完成后，怎么回到主线程继续执行？这就需要一个调度者，这个调度者就是事件循环（Event Loop）。
我用一个特别贴切的类比来解释：把 JS 主线程想象成一个老板，他一次只能处理一份文件。当老板遇到需要别人帮忙的事情（比如让前台查个资料、让财务做个报表），他不会站在原地干等，而是把这件事记下来，继续处理手头的下一份文件。等别人办完了，把结果交回来，老板再找时间处理。
这里的“记下来”就是任务队列，“找时间处理”就是事件循环在合适时机把回调捞回主线程执行。而浏览器就是那个前台——它不只有 JS 一个部门，还有渲染引擎、网络线程、定时器线程等，JS 通过 Web API 把任务交给这些后台线程，然后继续自己的事。
1.2 宏任务与微任务：两个不同优先级的“待办清单”
如果所有异步回调都塞进同一个队列，问题就来了：用户点击事件的回调、网络请求的回调、定时器的回调、DOM 渲染前的回调，这些任务的重要程度和紧急程度完全不同。所以事件循环设计了两个层级的队列：
- 宏任务队列（MacroTask Queue）：包括
setTimeout、setInterval、I/O 操作、UI 交互事件（如 click、scroll）、requestAnimationFrame等。 - 微任务队列（MicroTask Queue）：包括
Promise.then/catch/finally、queueMicrotask、MutationObserver等。
事件循环的规则是：每执行完一个宏任务，会立刻清空整个微任务队列；微任务队列清空后，如果页面需要渲染，就执行一次渲染；然后从宏任务队列里取下一个宏任务。注意关键词——每执行完“一个”宏任务，就要把微任务队列“整个”清空。
这意味着微任务的优先级显著高于宏任务。只要执行栈空了，事件循环会优先把微任务队列里的回调全部处理完，再去宏任务队列里取下一个任务。用前面老板的类比来说：老板做完了手头的一个大任务，会先把所有紧急的备忘录事项（微任务）一次性处理完，再去处理普通待办（宏任务）。
这里有一个非常磨人的细节：Promise 本身在创建时，构造函数里的代码是同步执行的，只有 then / catch / finally 里的回调才是微任务。setTimeout 的延迟时间只是“最快执行时间”，不是“保证执行时间”——如果微任务队列一直有任务，宏任务只能干等着。
javascript复制console.log('1 - 同步代码');
setTimeout(() => {
console.log('2 - 宏任务');
}, 0);
Promise.resolve()
.then(() => {
console.log('3 - 微任务');
});
console.log('4 - 同步代码');
// 输出顺序：1 -> 4 -> 3 -> 2
我见过很多同学第一次跑这段代码都很惊讶：明明 setTimeout 写在 Promise.resolve().then() 前面，为什么反而是微任务先输出？就是因为事件循环在“一个宏任务（这里宏任务指整个脚本）执行完”后，会先清空微任务队列，再去处理 setTimeout 对应的宏任务。这个顺序在浏览器和 Node.js 里基本一致（Node 的版本差异先不提，后面会说）。
2. Promise 深度解析：状态机与异步控制流
2.1 从回调地狱到 Promise：解决的不只是缩进问题
在 Promise 出现之前，JavaScript 处理异步主要靠回调函数。回调本身没问题，问题出在业务复杂之后——一个请求依赖另一个请求的结果，另一个请求又依赖上一个请求的参数，代码就变成了经典的“回调地狱”：
javascript复制requestA(function (resultA) {
requestB(resultA, function (resultB) {
requestC(resultB, function (resultC) {
requestD(resultC, function (resultD) {
// 继续嵌套...
});
});
});
});
这段代码最难受的地方还不是缩进深，而是逻辑被物理地“切碎”了。你不能像写同步代码那样用 try/catch 统一捕获错误，每个回调里都得单独判断错误；你也不能轻易地在多个异步任务之间做并行、竞争、重试等组合操作。
Promise 的价值在于：把“结果”和“等待结果的方式”拆开了。Promise 是一个状态机，代表一个尚未完成、但预期会完成的操作。它有三个状态：
- pending（待定）：初始状态，既没有完成也没有失败。
- fulfilled（已兑现）：操作成功完成，有结果值。
- rejected（已拒绝）：操作失败，有失败原因。
状态只能从 pending 变为 fulfilled 或 rejected，且一旦改变就不可逆。这个设计非常像现实中的“下单后不可取消的订单”——你可以等着它被配送（fulfilled），或者收到取消通知（rejected），但订单状态不可能从“已完成”变回“配送中”。
2.2 手写一个迷你 Promise：理解 then 的核心机制
很多教程直接丢给你官方规范，让人反而看不进去。其实 Promise 的核心机制，用一小段简化代码就能讲清楚。我们忽略掉各种边界情况，只看主干逻辑：
javascript复制class MyPromise {
constructor(executor) {
this.state = 'pending';
this.value = undefined;
this.reason = undefined;
this.onFulfilledCallbacks = [];
this.onRejectedCallbacks = [];
const resolve = (value) => {
if (this.state === 'pending') {
this.state = 'fulfilled';
this.value = value;
// 微任务调度，确保顺序
queueMicrotask(() => {
this.onFulfilledCallbacks.forEach((cb) => cb(value));
});
}
};
const reject = (reason) => {
if (this.state === 'pending') {
this.state = 'rejected';
this.reason = reason;
queueMicrotask(() => {
this.onRejectedCallbacks.forEach((cb) => cb(reason));
});
}
};
try {
executor(resolve, reject);
} catch (error) {
reject(error);
}
}
then(onFulfilled, onRejected) {
return new MyPromise((resolve, reject) => {
if (this.state === 'fulfilled') {
queueMicrotask(() => {
try {
const result = onFulfilled(