事件循环中的“调用栈”和“任务队列”如何交互？-js教程-PHP中文网

javascript的调用栈是用于跟踪代码执行流程的后进先出（lifo）结构，负责同步代码的即时执行；当函数调用时，其执行上下文压入栈顶，执行完毕后弹出；若同步任务耗时过长，会阻塞主线程，影响性能和用户体验。

事件循环中的“调用栈”和“任务队列”如何交互？

在JavaScript的非阻塞世界里，事件循环（Event Loop）是幕后的真正英雄，它巧妙地编排着“调用栈”（Call Stack）和“任务队列”（Task Queue）之间的协作。简单来说，调用栈负责同步代码的即时执行，而任务队列则存放着待处理的异步任务。它们的交互核心在于，事件循环会持续不断地检查调用栈是否为空，一旦为空，它就会从任务队列中取出下一个待执行的任务，将其推入调用栈，从而确保了代码的连续运行和用户界面的响应性。

理解这个机制，你就能明白为什么JavaScript虽然是单线程的，却能处理复杂的异步操作，比如网络请求、定时器或者用户交互。

事件循环是JavaScript运行时模型的核心，它像一个永不停歇的调度员。当一段脚本开始执行时，所有同步代码都会被推入调用栈，并按照后进先出（LIFO）的原则立即执行。这个过程是阻塞的，也就是说，如果同步代码执行时间过长，页面就会“卡住”。

一旦遇到异步操作，比如setTimeout、fetch或用户点击事件，这些操作并不会直接在调用栈中等待。它们会被移交给浏览器或Node.js的宿主环境去处理。当这些异步操作完成时，它们的回调函数并不会立即回到调用栈，而是会被放入相应的“任务队列”中排队。

这里有个关键点：任务队列实际上分为两种，微任务队列（Microtask Queue）和宏任务队列（Macrotask Queue）。像Promise的回调（.then()、.catch()、.finally()）和MutationObserver的回调属于微任务；而setTimeout、setInterval、I/O操作、UI渲染事件等则属于宏任务。

事件循环的工作流程是这样的：

调用栈清空：执行所有同步代码直到调用栈为空。
微任务优先：事件循环会检查微任务队列。如果里面有任务，它会清空并执行所有微任务，直到微任务队列为空。
宏任务接力：当微任务队列也清空后，事件循环会从宏任务队列中取出一个（注意，每次循环只取一个）任务，将其对应的回调函数推入调用栈执行。
循环往复：宏任务执行完毕，调用栈再次清空，事件循环又回到步骤2，如此循环往复。

这个机制确保了即使有大量异步操作，JavaScript也能保持响应，并且微任务拥有更高的执行优先级，这对于某些需要即时反馈的异步操作（如Promise链）至关重要。

JavaScript的调用栈究竟是什么，它在代码执行中扮演了怎样的角色？

调用栈，你可以把它想象成一个用于跟踪程序执行流程的堆栈数据结构。当JavaScript代码开始运行时，它就是一个后进先出（LIFO）的结构，用来存储程序执行期间的各种“执行上下文”。每当一个函数被调用时，一个新的执行上下文就会被创建并压入调用栈的顶部。这个上下文包含了函数的参数、局部变量以及函数执行到哪里的信息。

比如，你写了一个函数A，A里面又调用了函数B，B里面又调用了函数C。当代码执行到C时，调用栈的顶端就是C的执行上下文，下面是B的，最底部是A的。当C执行完毕，它的上下文就会从栈顶弹出；接着B执行完弹出，最后A执行完也弹出。

调用栈的这种特性决定了JavaScript同步代码的执行方式：一旦某个函数进入调用栈，它就必须完全执行完毕才能弹出，除非遇到异常。这意味着，如果一个函数内部有非常耗时的计算，它会一直占据着调用栈，直到计算完成，期间任何其他代码都无法执行，包括用户界面的更新。这就是为什么我们常说“JavaScript是单线程的”，并且长时间的同步操作会“阻塞”主线程。理解这一点，对于我们编写高性能、响应式的前端应用至关重要，它直接关系到用户体验。

微任务和宏任务有何不同，为什么这种区分对异步编程至关重要？

微任务和宏任务是事件循环中两种不同优先级的任务类型，它们的区分是JavaScript异步模型中一个非常精妙且关键的设计。

宏任务（Macrotasks），也常被称为任务（Tasks），它们是相对“粗粒度”的任务。典型的宏任务包括：

setTimeout() 和 setInterval() 的回调
I/O 操作（例如网络请求完成后的回调）
UI 渲染事件（如requestAnimationFrame，虽然它在某些浏览器中行为可能更接近微任务，但概念上属于宏任务层面的调度）
setImmediate()（Node.js特有）

每次事件循环迭代（或者说，每次事件循环从宏任务队列中取出一个任务并执行）只会处理一个宏任务。当一个宏任务执行完毕，事件循环才会检查微任务队列。

微任务（Microtasks），则更为“细粒度”，它们拥有更高的优先级。典型的微任务包括：

AppMall应用商店

AI应用商店，提供即时交付、按需付费的人工智能应用服务

查看详情

Promise.prototype.then()、.catch()、.finally() 的回调
MutationObserver 的回调
queueMicrotask()

在一个宏任务执行完毕后，事件循环会立即清空并执行所有当前微任务队列中的微任务，直到微任务队列为空。只有当微任务队列完全清空后，事件循环才会去宏任务队列中取出下一个宏任务。

这种区分为什么重要？

优先级和即时性： 微任务的优先级高于宏任务。这意味着如果你在一个宏任务中触发了多个微任务，这些微任务会在下一个宏任务开始之前全部执行。这对于需要更即时反馈的异步操作（如Promise链）非常关键，它们可以保证在当前事件循环周期内完成。例如，如果你有一个Promise链，.then()的回调会比任何setTimeout(..., 0)的回调更早执行。
避免UI阻塞： 如果没有微任务，所有异步回调都会进入宏任务队列。想象一下，一个复杂的Promise链可能需要多次事件循环才能完成，这会大大延迟UI的更新。微任务的存在允许Promise链在当前宏任务结束后立即完成，从而更快地响应用户操作或数据更新，而无需等待下一个完整的宏任务周期。
精确控制执行顺序： 这种优先级机制让开发者能更精确地控制异步代码的执行顺序。例如，你可以在一个异步操作完成后立即执行一些清理或后续逻辑，而不用担心被其他宏任务“插队”。

理解微任务和宏任务的区别，是编写高效、响应式JavaScript代码的关键。它能帮助你避免一些常见的异步陷阱，比如预期之外的执行顺序，或者UI更新延迟。

事件循环是否会被阻塞，以及这会如何影响应用程序的性能和用户体验？

是的，事件循环是会被阻塞的，而且一旦发生，后果通常很严重，直接影响到应用程序的性能和用户体验。虽然事件循环的目的是让JavaScript保持非阻塞，但它本身依赖于调用栈的清空。如果调用栈长时间不空，事件循环就无法将任务队列中的任务推入栈中，从而导致阻塞。

事件循环被阻塞的常见原因：

长时间运行的同步代码： 这是最常见的原因。如果你的JavaScript代码中存在一个计算量巨大、执行时间很长的同步函数（例如，复杂的数学运算、大型数组的排序、没有合理分块的循环），它会一直霸占着调用栈。只要这个函数不返回，调用栈就无法清空，事件循环也就无法进行下一轮迭代。这意味着，宏任务（如UI事件、定时器回调）和微任务都无法被处理。
无限循环或死循环： 如果代码中不小心写了一个无限循环（while(true)或递归没有终止条件），调用栈将永远无法清空，事件循环将完全停滞。
微任务队列的“饥饿”现象（理论上可能，实际较少见）： 尽管微任务优先级高，但如果一个微任务不断地生成新的微任务（例如，一个Promise .then()回调里又返回了一个新的Promise，并且这个链条没有尽头），那么微任务队列可能会无限增长，导致宏任务永远无法执行。这会使得UI更新、定时器等宏任务得不到执行，最终表现为页面卡死。

对应用程序性能和用户体验的影响：

UI无响应（“卡死”）： 这是最直接也是最明显的影响。当事件循环被阻塞时，浏览器无法处理用户的交互事件（点击、滚动、输入），也无法进行页面重绘。用户会看到一个“冻结”的页面，鼠标指针可能变成沙漏或加载图标，浏览器甚至会弹出“页面无响应”的警告。
动画卡顿： 依赖于requestAnimationFrame（通常在宏任务周期中调度）或setTimeout的动画会停止更新，表现为画面定格或严重卡顿。
定时器失效： setTimeout和setInterval的回调函数无法按时执行，因为它们的回调被困在宏任务队列中，等待事件循环去处理。
网络请求回调延迟： 虽然网络请求本身在后台进行，但当请求完成后，其回调函数（通常是宏任务）也需要等待事件循环的空闲才能被执行，导致数据加载完成后，页面却迟迟没有反应。

如何避免阻塞：

拆分长时间任务： 将耗时计算分解成小块，使用setTimeout(..., 0)或requestAnimationFrame将它们分散到多个事件循环周期中执行，给浏览器喘息的机会。
使用Web Workers： 对于真正密集的CPU计算，将其 offload 到Web Worker中。Web Worker运行在独立的线程，不会阻塞主线程的事件循环。
合理使用异步模式： 充分利用Promise、async/await来处理异步操作，确保同步代码尽可能精简。
性能分析： 使用浏览器开发者工具（如Chrome DevTools的Performance面板）来识别和定位导致阻塞的“长任务”。