至于前言，JS事件循环，为何代码输出总出错？

相信很多第一次接触 JS 异步的小伙伴很容易被搞懵：明明写在前面的定时器 `setTimeout` 为什么总是比后面的 `Promise` 回调执行晚？为什么代码逻辑明明没问题，输出顺序却完全错乱？这与 事件循环有着莫大的关系。我第一次也在这里踩了无数坑。这篇文字将带你五分钟彻底搞懂 JS 事件循环机制，告别异步困惑！

一、 根源：JS 的单线程模型

在深入复杂的机制前，我们必须先明确 JS 的运行本质。这是导致所有问题的根源：

1. 默认单线程执行

JS 引擎是单线程的，这代表着它同一时刻只能执行一条代码。

2. 为什么不设计成多线程模式？

• 因为 JS 可以直接操作 DOM 结构。其实，如果采用多线程执行。可能会出现多个线程同时修改同一个元素，导致不安全的渲染结果。

• 多线程需要复杂的“锁”机制来防止冲突，这会极大地增加开发难度并带来性能开销。其实，

二、 任务分类：宏任务 vs 微任务

为了不让耗时任务阻塞主线程，JS 将异步任务分成了两大阵营：

1. 宏任务

也称为任务队列，执行优先级较低：

• setTimeout
• setInterval
• ajax
• I/O 操作
• UI-rendering

2. 微任务

执行优先级极高。会在每一个宏任务执行完后立即清空微任务队列：

• promise.n
• process.nextTick
• MutationObserver

⚠️ 特别注意：setTimeout 的坑

• 所有的 setTimeout 共用同一份计时器。 先进入宏任务队列的不一定先执行，而是根据计时时间长短来判断是否已经就绪。

三、 事件循环的执行机制

这是解决“输出出错”的关键，请严格牢记以下执行顺序：

1. 执行同步任务： script 属于第一个宏任务。执行过程中，遇到异步任务就将它们分别存入对应的队列。
2. 清空微任务队列： 同步代码执行完成后立即去微任务队列中查找。并执行所有已存在的微任务，直到队列为空。
3. 渲染页面：在需要的情况下浏览器会进行 UI 渲染。老实说，
4. 执行下一个宏任务：从宏任务队列中取出第一个宏任务进行执行。

说到实战演练，代码执行顺序

上述规则这方面。

console.log;// 同步
new Promise => {
console.log;// 同步
resolve
}).n => {
console.log;// 微任务
setTimeout => {
console.log;// 宏任务
},0)
})
setTimeout => {
console.log;
// 宏任务
},0)
console.log;
// 同步

执行步骤解析：

1. 第一步先： 输出 1；执行 Promise 构造函数，输出 2；遇到 .n 存入微任务队列；setTimeout2 存入宏任务队列；最终输出 6，
2. 接下来： 微任务队列发现有 n取出执行输出 3；紧接着触发了 setTimeout1存入宏任务队列。此时微任务队列清空，不过，
3. 然后： 无需渲染。
4. 第四步： 宏任务队列有两个定时器。由于它们共用计时且 setTimeout1 先进入。所以先输出 4，再输出 5。

流程图直击：

graph LR
A --> B
B --> C{异步代码?说起来，}
C -->|微任务| D
C -->|宏任务| E
D --> F{后续同步代码是否执行完?}
E --> F
F -->|否| B
F -->|是| G
G --> H

四、进阶：Async/Await 的本质

async/await 是 Promise 的语法糖，理解它们：

• 函数前加 async 等同于该函数返回了一个 Promise 对象。
• await xxx 相当于 .n。它会阻塞当前函数的后续代码执行，并将这些后续代码挤入 微任务队列。其实，