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

JavaScript事件循环确保异步任务有序执行：同步任务先执行，随后清空微任务队列（如Promise回调），再执行一个宏任务（如setTimeout），如此循环。微任务优先级高于宏任务，保证高优先级回调快速响应。常见宏任务包括script、setTimeout、setInterval、I/O操作；微任务有Promise.then、MutationObserver、queueMicrotask等。例如，console.log('Start')和console.log('End')作为同步任务最先输出；接着执行两个Promise.then中的Promise 1和Promise 2；然后执行setTimeout的setTimeout 1，其内部Promise.then的回调Promise inside setTimeout紧随其后（因微任务清空机制）；最后是setTimeout inside Promise。这体现微任务在宏任务之间“插队”的特性。使用async/await可提升代码可读性，避免回调地狱；setTimeout(fn, 0)并非立即执行，仍为宏任务，优先级低于微任务；需UI渲染相关操作时可用requestAnimationFrame；耗时计算应移至Web Workers以避免阻塞主线程；利用queueMicrotask可在当前宏任务结束后、下一宏任务前执行高优先级任务，实现更精细控制。开发者工具Performance面板有助于分析任务执行顺序与性能瓶颈。掌握事件循环机制有助于编写更可预测的异步代码，避免常见陷阱。

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

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

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

它的工作原理是这样的：当JS引擎执行代码时，会有一个调用栈（Call Stack）来处理同步任务。遇到异步任务，比如

setTimeout

fetch

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

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

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

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

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

当我们在JS代码中调用像

setTimeout

fetch

addEventListener

setTimeout(callback, 1000)

fetch

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

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

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

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

• script

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