前言

在前端开发中，是不是经常被JS的异步代码绕晕？按理说，明明写的代码顺序一样，运行结果却大相径庭？其实主要原因就在于——JS是单线程语言，而异步操作全靠「Event-Loop」来调度。今天就结合具体代码案例，从进程线程、V8引擎到Event-Loop、async/await，一步步拆解，让你搞懂JS异步的根本原因~

一、先搞基础：进程 vs 线程

在聊JS异步之前，我们得先分清两个容易混淆的概念：进程和线程。这是理解后续内容的基石～

• 进程 ：简单进程就是CPU运行指令、加载和保存上下文所需的“容器”，是程序运行的独立单位。比如你打开浏览器，每多开一个Tab页。就相当于多开启了一个进程，每个进程之间相互独立，互不干扰。

• 线程 ：线程是进程内的执行单元，是CPU实际执行指令的“最小单位”。一个进程可以包含多个线程，这些线程共享进程的资源，协同完成任务。其实，

举个浏览器的例子：每个浏览器Tab进程中，会包含多个主要线程。其中和我们JS相关的有3个：

1. 再看渲染线程，负责渲染页面；

2. 再看JS引擎线程，负责执行JS代码；

3. HTTP请求线程：负责发送网络请求。

这里有个关键知识点⚠️：因为JS代码可以修改DOM，如果JS引擎线程和渲染线程同时运行。会导致页面渲染混乱，所以JS引擎线程和渲染线程是互斥的——说白了JS代码执行时渲染线程会暂停，等JS执行完，渲染线程才会继续工作。这也是为什么有时候JS代码写得太复杂。页面会出现“卡顿”的原因～

二、V8引擎：JS单线程的“幕后推手”

我们写的JS代码，最终是由V8引擎来执行的。而V8引擎在执行JS代码时默认只开启一个JS引擎线程——这就代表着。JS代码只能“自上而下、依次执行”，同一时间只能做一件事。

再看那问题来了。如果JS遇到耗时操作，难道要一直等着设置完成，再继续执行后续代码吗？ 这样会导致页面卡死，使用者体验直接拉胯！

为了解决这个问题，JS引入了「异步机制」：单线程处理代码时遇到同步任务就立即执行；遇到异步任务不等待、不阻塞。而是把它暂时存放到“任务队列”中，等JS引擎线程空闲时再去执行任务队列中的异步任务。

三、主要主要：Event-Loop 事件循环

Event-Loop就是JS处理异步任务的“调度器”，它的执行流程决定了所有同步、异步代码的运行顺序。我们先明确两个主要概念：微任务和宏任务——所有异步任务，都会被分到这两个队列中。

微任务 vs 宏任务

微任务和宏任务的区别。在于它们的“优先级”：微任务优先级高于宏任务，会先于宏任务执行。

• 微任务 ：

  • Promise.n、Promise.catch、Promise.finally

  • process.nextTick

  • MutationObserver

• 宏任务 ：

  • 整个script脚本

  • setTimeout 、 setInterval

  • AJAX请求 、 I/O操作

  • UI渲染

  易错点提醒⚠️ ： 很多人会误以为 “setTimeout” 会立即执行。其实不然 ——setTimeout 的 延迟时间是 “最小延迟 ”，不是 “精确延迟 ”，即使设为0，也会被放入宏任务队列，等待同步代码 、 微任务全部执行完毕后，才会执行。

Event-Loop 执行顺序

记住这个顺序，就能搞定80% 的 异步代码输出题。结合后面 的 代码案例理解更透彻 👇 ：

1. 先执行 同步代码 ，执行过程中遇到异步任务，就分别存入微任务队列 、 宏任务队列；老实说，

2. 同步代码执行完毕后。清空 微任务队列 （所有微任务依次执行，执行过程中产生 的 新微任 务，也会在本次微任 务队列中执 行完毕）；

3. 微任 务全部执 行结束后若有需要，浏览器会进 行 页面渲 染 ；

4. 渲 染完成后从 宏任 务队列 中取出第 一个 宏任 务执 行（执 行该宏任 务的过程 中。遇 到同步 、异 步任 务，重 复步骤1-）；

5. 重 复步骤1-。形 成 “循 环 ”，这就是Event-Loop。

说到代码实操。搞懂Event-Loop执 行顺序

💡 关

键 提 醒： async函 数 内，await前面 的 代 码 是 同 步执 行 的；不过，await后面 的 代 码 会 被 放 入 微 任 务队 列。和Promise.n 的 微 任 务优 先 级 相 同，按顺 序执 行。

五、