事件循环与调用栈：JS运行核心机制解析

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《事件循环与调用栈是JavaScript运行的核心机制，它们紧密关联但职责不同。调用栈用于跟踪函数调用的顺序，而事件循环则负责处理异步操作。两者共同确保JavaScript在单线程环境下高效执行任务。》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

JavaScript的单线程特性通过事件循环和调用栈实现异步操作。1. 调用栈是LIFO结构，负责同步代码执行；2. 异步任务交由宿主环境处理，完成后回调放入任务队列；3. 事件循环持续检查调用栈，若为空则将队列中的回调推入栈执行；4. 微任务（如Promise）优先于宏任务（如setTimeout）在当前任务结束后立即执行。这种机制确保主线程不阻塞，实现非阻塞I/O和并发效果。

JavaScript中，事件循环（Event Loop）和调用栈（Call Stack）是其并发模型的核心组件，它们协同工作，共同决定了代码的执行顺序，尤其是在处理异步操作时。简单来说，调用栈负责同步代码的立即执行，而事件循环则像一个永不停歇的协调者，它不断检查调用栈是否为空，并根据任务队列的情况将异步任务的回调函数推入调用栈，从而实现非阻塞的I/O操作和并发的错觉。

解决方案

要理解事件循环和调用栈的关系，我们得先拆开看它们各自扮演的角色，再把它们放到一起。调用栈，顾名思义，是一个LIFO（后进先出）的数据结构，它负责跟踪当前正在执行的函数。每当一个函数被调用，它就会被推入调用栈；当函数执行完毕，它就会从栈中弹出。所有的同步代码都在这个栈上顺序执行。如果一个函数执行时间过长，它会阻塞整个栈，导致页面无响应，这就是所谓的“阻塞式”执行。

而事件循环则是在这个单线程环境中实现“非阻塞”的关键。JavaScript引擎本身是单线程的，这意味着它一次只能做一件事。为了处理像网络请求、定时器、用户交互这类耗时的异步操作，浏览器（或Node.js环境）提供了一些Web API（如setTimeout, fetch, DOM事件等）。当这些异步操作完成时，它们的回调函数并不会立即执行，而是被放入一个“任务队列”（或称“回调队列”）。事件循环的工作就是持续不断地检查调用栈是否为空。一旦调用栈清空了，事件循环就会从任务队列中取出一个回调函数，将其推入调用栈，使其得以执行。这个过程周而复始，形成一个循环，确保了即便有耗时操作，主线程也不会被卡死，而是能继续响应用户界面或处理其他任务。

所以，它们的关系就是：调用栈是舞台，所有同步的表演者都在上面即时演出；而事件循环是导演，它在舞台空闲时，将后台准备好的异步表演者（回调函数）安排上台。没有事件循环，调用栈就无法处理异步任务；没有调用栈，事件循环也无处安放其调度好的任务。

JavaScript的单线程特性如何与异步操作和谐共存？

这其实是很多初学者会感到困惑的地方。我们常说JavaScript是单线程的，这意味着它只有一个调用栈，同一时间只能执行一段代码。那问题就来了，如果我发起一个网络请求，需要几秒钟才能返回数据，这几秒钟难道整个页面就卡死了吗？当然不是。这就是事件循环和宿主环境（浏览器或Node.js）提供的Web API/Node API发挥作用的地方。

当JavaScript代码中遇到一个异步操作，比如fetch('some-url')或者setTimeout(callback, 1000)时，这些操作本身并不会在JavaScript主线程上执行。相反，它们会被移交给宿主环境（浏览器内核的C++部分，或者Node.js的libuv库）去处理。你可以把这些Web API或Node API想象成一些“外包工人”，它们在后台默默地执行这些耗时任务。

一旦这些“外包工人”完成了任务（比如网络请求返回了数据，或者定时器时间到了），它们并不会直接把结果塞回JavaScript主线程。它们会将对应的回调函数（也就是我们写在then()或setTimeout()里的函数）放入一个特定的队列中，这个队列就是“任务队列”（或“消息队列”）。而JavaScript的事件循环，就像一个永不停歇的监工，它会不断地检查两件事：一是调用栈是否为空（即主线程当前没有同步代码在执行），二是任务队列里有没有待处理的回调函数。只有当调用栈为空时，事件循环才会从任务队列中取出一个回调函数，将其推入调用栈，让JavaScript主线程去执行它。

这种机制确保了JavaScript主线程始终保持响应，不会因为等待某个耗时操作而阻塞。它巧妙地利用了单线程的特性，通过将耗时任务“外包”出去并在完成后排队等待，实现了非阻塞的异步编程模型。这就像你在餐厅点菜，厨房（宿主环境）去准备菜（异步任务），你（JS主线程）可以继续喝茶聊天（执行其他同步代码），等菜好了（异步任务完成），服务员（事件循环）会把菜端给你（回调函数被推入调用栈）。

理解setTimeout(fn, 0)的执行时机：它真的会立即执行吗？

这是一个经典的面试题，也是理解事件循环机制的绝佳切入点。直觉上，setTimeout(myFunction, 0)会让人觉得myFunction应该立即执行，毕竟延迟是0毫秒嘛。但实际情况并非如此。

当你调用setTimeout(myFunction, 0)时，myFunction并不会被立即推入调用栈执行。相反，setTimeout这个函数本身会立即执行，它会把myFunction这个回调函数连同指定的延迟时间（这里是0毫秒）一起，交给Web API（在浏览器环境下）或Node API（在Node.js环境下）去处理。Web API会启动一个定时器，并在0毫秒后将myFunction放入“宏任务队列”（Macrotask Queue）中。

请注意，这里是“宏任务队列”，而不是直接推入调用栈。JavaScript的事件循环机制规定，只有当调用栈完全清空（即所有同步代码都执行完毕）后，事件循环才会去检查宏任务队列。如果宏任务队列中有任务，它会取出第一个任务（也就是我们的myFunction），然后将其推入调用栈执行。

这意味着，即使延迟时间是0，myFunction也必须等到当前正在执行的所有同步代码都完成，并且调用栈清空后，才有机会被执行。如果你的同步代码非常耗时，或者前面还有其他已经排队等待的宏任务，那么myFunction的实际执行时间可能会远超0毫秒。

举个例子：

console.log('Start');

setTimeout(() => {
  console.log('setTimeout callback');
}, 0);

for (let i = 0; i < 1000000000; i++) {
  // 模拟一个非常耗时的同步操作
}

console.log('End');

这段代码的输出顺序会是：Start -> End -> setTimeout callback。即使setTimeout的延迟是0，它也必须等到那个巨大的for循环执行完毕，console.log('End')执行完毕，调用栈清空后，setTimeout的回调才有机会被事件循环推入调用栈。这个例子清晰地展示了setTimeout(fn, 0)并非立即执行，而是需要等待当前事件循环周期中的同步任务完成。

微任务（Microtasks）与宏任务（Macrotasks）在事件循环中的优先级与处理机制

随着JavaScript异步编程的演进，特别是Promise的引入，事件循环的机制变得更加精细。现在，任务队列不再是单一的，而是分为两大类：宏任务（Macrotasks）和微任务（Microtasks）。理解它们的优先级对于编写复杂的异步代码至关重要。

宏任务（Macrotasks） 宏任务是那些通常由宿主环境（浏览器或Node.js）发起的，每次事件循环迭代中只处理一个的任务。常见的宏任务包括：

• setTimeout()
• setInterval()
• DOM事件（如点击、加载）
• requestAnimationFrame (在某些实现中被认为是宏任务，但其调度更复杂)
• I/O操作（在Node.js中）

每次事件循环迭代，会从宏任务队列中取出一个任务来执行。

微任务（Microtasks） 微任务是那些优先级更高的任务，它们在当前宏任务执行完毕后，但在下一个宏任务开始之前，会立即被执行。也就是说，在每个宏任务执行结束后，事件循环会清空所有微任务队列中的任务，然后才进入下一个宏任务的执行。常见的微任务包括：

• Promise的回调（then(), catch(), finally()）
• async/await（本质上是基于Promise的语法糖）
• MutationObserver
• queueMicrotask()

处理机制与优先级

事件循环的每轮迭代大致遵循以下步骤：

1. 执行一个宏任务： 事件循环从宏任务队列中取出一个宏任务，并将其推入调用栈执行。
2. 清空微任务队列： 在当前宏任务执行完毕后，事件循环会检查微任务队列。如果队列中有任务，它会逐个取出并执行，直到微任务队列完全清空。
3. 渲染（可选）： 在浏览器环境中，清空微任务队列后，可能会进行一次页面渲染（重绘和回流），这通常发生在下一个宏任务开始之前。
4. 进入下一轮宏任务： 清空微任务并完成渲染后，事件循环会再次从宏任务队列中取下一个宏任务，重复以上步骤。

这意味着，Promise的回调（微任务）总是会在当前宏任务执行完毕后，且在任何新的宏任务（包括setTimeout(fn, 0)的回调）执行之前被执行。

举个例子：

console.log('Script start');

setTimeout(() => {
  console.log('setTimeout callback (Macrotask)');
}, 0);

Promise.resolve().then(() => {
  console.log('Promise callback (Microtask 1)');
}).then(() => {
  console.log('Promise callback (Microtask 2)');
});

console.log('Script end');

这段代码的输出顺序会是：

1. Script start (同步代码)
2. Script end (同步代码)
3. Promise callback (Microtask 1) (当前宏任务（整个script）执行完毕后，立即执行所有微任务)
4. Promise callback (Microtask 2) (继续执行所有微任务)
5. setTimeout callback (Macrotask) (所有微任务清空后，进入下一轮事件循环，执行下一个宏任务)

这个例子清楚地展示了微任务比宏任务具有更高的优先级，它们会在当前宏任务结束后“插队”执行，然后再轮到下一个宏任务。理解这一点对于预测异步代码的行为，尤其是在处理复杂的Promise链和async/await逻辑时，至关重要。

终于介绍完啦！小伙伴们，这篇关于《事件循环与调用栈：JS运行核心机制解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！