JS事件循环：宏任务与微任务解析

JavaScript事件循环是单线程环境下实现高效异步处理的核心机制，其关键在于宏任务（如setTimeout、script）与微任务（如Promise.then、queueMicrotask）之间严格的优先级规则：同步代码执行完毕后，立即清空全部微任务队列，再执行一个宏任务，如此循环往复——这使得微任务总能“插队”在宏任务之间，确保高响应性操作（如Promise回调、DOM变更通知）及时执行；深入理解这一机制不仅能解释看似反直觉的代码执行顺序，更能帮助开发者规避setTimeout(fn, 0)的误区、合理选用async/await、requestAnimationFrame或Web Workers，并借助Performance面板精准优化性能，最终写出更可靠、可预测且高性能的异步代码。

JavaScript事件循环是其异步执行的核心机制，它决定了代码的执行顺序。简单来说，微任务（如Promise回调）总是在当前宏任务（如脚本执行、setTimeout回调）结束之后、下一个宏任务开始之前被清空，这赋予了微任务更高的优先级。

JS 事件循环机制剖析 - 宏任务与微任务的优先级执行顺序解析

要理解JS的事件循环，我们得先接受一个基本事实：JavaScript是单线程的。这意味着它一次只能做一件事。但我们又常常需要处理网络请求、定时器、用户交互这些耗时的异步操作，如果都阻塞主线程，那用户体验简直是灾难。事件循环（Event Loop）就是解决这个矛盾的关键。

它的工作原理是这样的：当JS引擎执行代码时，会有一个调用栈（Call Stack）来处理同步任务。遇到异步任务，比如setTimeout或fetch，JS引擎并不会停下来等待，而是将这些任务交给浏览器（或Node.js环境）的Web API模块去处理。当Web API完成任务后，它会将对应的回调函数放入一个队列。这里就分成了两个关键的队列：宏任务队列（Macrotask Queue，也常被称为任务队列 Task Queue）和微任务队列（Microtask Queue）。

事件循环会持续不断地检查调用栈是否为空。一旦调用栈空了，它就会先去微任务队列里，把所有等待的微任务一个个取出来，放到调用栈里执行，直到微任务队列清空。只有当微任务队列彻底空了之后，事件循环才会去宏任务队列里取出一个（注意，是“一个”）宏任务，放到调用栈里执行。这个宏任务执行完毕后，又会再次检查微任务队列，如此循环往复。

所以，核心的优先级顺序就是：同步任务 > 所有微任务 > 一个宏任务 > 所有微任务 > 另一个宏任务... 这种机制确保了某些高优先级的异步操作（如Promise的then回调）能够尽快响应，而不会被其他耗时的宏任务长时间阻塞。

为什么JavaScript是单线程的，它如何处理异步操作？

我常常会想，为什么JavaScript当初被设计成单线程？这背后其实有很实际的考量。想象一下，如果JS是多线程的，同时操作DOM，一个线程想删除一个元素，另一个线程想修改它，那最终的结果会是怎样？这简直是一场混乱。单线程简化了编程模型，避免了复杂的并发问题，尤其是在浏览器环境中，它能够确保UI渲染的一致性。

但单线程也带来了挑战：耗时操作会阻塞UI。为了解决这个问题，JS引入了“非阻塞”的异步处理模式。这并不是说JS真的变成了多线程，而是它巧妙地利用了宿主环境（浏览器或Node.js）提供的能力。

当我们在JS代码中调用像setTimeout、fetch、addEventListener这样的异步函数时，JS引擎只是把这些任务“委托”给了Web API。比如setTimeout(callback, 1000)，浏览器内部的计时器开始倒计时。fetch请求发出后，浏览器网络模块去处理。当这些异步操作完成，它们的回调函数并不会立即执行，而是被放入相应的队列等待。

事件循环扮演的角色就像一个“调度员”。它不断地监控着调用栈和这些任务队列。当主线程（调用栈）空闲时，它就会按照优先级规则（先微任务，后宏任务，且宏任务一次只取一个）把队列中的回调函数推到调用栈中执行。这个过程是持续的，确保了即使是单线程，JS也能高效地处理大量的异步任务，让用户界面保持响应。在我看来，这是一种非常优雅的设计权衡。

宏任务与微任务的具体类型有哪些？它们在实际开发中如何影响代码行为？

理解宏任务和微任务的具体类型，是掌握事件循环的关键，也是避免一些“意想不到”行为的基础。

常见的宏任务（Macrotasks）包括：

• script (整体代码块执行)：你整个JS文件或