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，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文件或<script>
标签内的代码，它本身就是第一个宏任务。 -
setTimeout()
和setInterval()
的回调：这是最常见的宏任务，它们的回调函数会在指定时间后被放入宏任务队列。 - I/O 操作：比如文件的读写（Node.js中）。
- UI 渲染：浏览器在每次事件循环迭代中，可能会决定进行一次UI渲染。
-
requestAnimationFrame()
：虽然它与UI渲染紧密相关，且通常在渲染前执行，但行为上更像是一种特殊的宏任务，或者说有自己的执行时机。 -
MessageChannel
：用于跨文档或Worker通信。 -
setImmediate()
(Node.js)：与setTimeout(fn, 0)
类似，但优先级略有不同。
常见的微任务（Microtasks）包括：
-
Promise.then()
/catch()
/finally()
的回调：这是最核心的微任务类型。 -
MutationObserver
的回调：用于监听DOM变化。 -
queueMicrotask()
：这是一个明确将任务放入微任务队列的API。 -
process.nextTick()
(Node.js)：在Node.js中，它的优先级甚至高于其他微任务，会在当前操作结束后立即执行。
在实际开发中，它们的优先级差异会直接影响代码的执行顺序。举个例子：
console.log('Start'); // 同步任务
setTimeout(() => {
console.log('setTimeout 1'); // 宏任务
Promise.resolve().then(() => {
console.log('Promise inside setTimeout'); // 微任务
});
}, 0);
Promise.resolve().then(() => {
console.log('Promise 1'); // 微任务
setTimeout(() => {
console.log('setTimeout inside Promise'); // 宏任务
}, 0);
});
Promise.resolve().then(() => {
console.log('Promise 2'); // 微任务
});
console.log('End'); // 同步任务你觉得这段代码的输出顺序会是什么？
Start
(同步)End
(同步)Promise 1
(第一个宏任务执行完，清空微任务队列)Promise 2
(清空微任务队列)setTimeout 1
(取出一个宏任务执行)Promise inside setTimeout
(setTimeout 1
执行完，清空微任务队列)setTimeout inside Promise
(取出一个宏任务执行)
这清晰地展示了微任务如何插队在宏任务之间。有时候，我看到一些新手开发者会把
setTimeout(fn, 0)当成是“立即执行”的，但实际上它仍然是宏任务，优先级远低于
Promise.then()。理解这一点，对于避免一些难以追踪的异步bug至关重要。
如何编写更可预测的异步代码，避免事件循环带来的常见陷阱？
要写出可预测的异步代码，首先得把事件循环的机制刻在脑子里。我个人在实践中总结了一些经验，希望能帮助大家少踩坑。
拥抱
Promise
和async/await
： 它们是现代JS处理异步的主流方式。async/await
实际上是Promise
的语法糖，它让异步代码看起来更像同步代码，极大地提高了可读性和可维护性。当你在async
函数中使用await
时，await
后面的代码会被暂停，直到Promise
解决，而await
之后的代码会作为微任务在Promise
解决后立即执行。这比回调地狱（callback hell）要好太多了。警惕
setTimeout(fn, 0)
的“欺骗性”： 尽管延迟是0，但它仍然是一个宏任务。如果你需要一个在当前同步代码块执行完后，但又在下一个渲染帧或下一个完整事件循环周期前执行的任务，Promise.resolve().then()
或queueMicrotask()
往往是更合适的选择。比如，我想在DOM更新后立即执行某个操作，但又不希望等到下一个渲染周期，我会优先考虑微任务。理解
requestAnimationFrame
的定位： 如果你的任务是与UI渲染紧密相关的，比如动画或者在浏览器重绘前进行DOM操作，requestAnimationFrame
是首选。它会在浏览器下一次重绘之前执行，能确保动画的流畅性，避免“抖动”。它的执行时机通常在宏任务之后、浏览器渲染之前。避免在主线程中执行耗时计算： 即使你把代码放在
Promise.then()
里，如果这个then
里的回调函数本身执行时间很长，它依然会阻塞主线程，导致页面卡顿。对于CPU密集型任务，考虑使用Web Workers
。Web Workers
运行在独立的线程中，不会阻塞主线程，通过postMessage
进行通信。善用浏览器开发者工具： Chrome DevTools 的 Performance 面板是分析事件循环行为的利器。你可以录制页面加载或交互过程，然后查看主线程的调用栈、任务队列、微任务队列的执行情况，哪些任务耗时，哪些任务阻塞了渲染。这比单纯地猜测代码执行顺序要高效得多。
-
代码示例：
queueMicrotask
的妙用 有时候，我们可能需要在当前代码块执行完毕后，立即执行一些高优先级的清理或状态更新，而不是等到下一个宏任务。queueMicrotask()
在这种场景下就很有用。console.log('Script start'); function processData() { console.log('Processing data...'); // 假设这里有一些耗时但不阻塞UI的计算 } // 假设我们希望在当前脚本执行完，但在任何 setTimeout 之前执行 processData queueMicrotask(() => { processData(); console.log('Data processed via microtask'); }); setTimeout(() => { console.log('setTimeout callback'); }, 0); console.log('Script end');输出会是：
Script start
Script end
Processing data...
Data processed via microtask
setTimeout callback
这清晰地展示了
queueMicrotask
如何确保其回调在当前宏任务（整个脚本）结束后，所有其他微任务之后，但在下一个宏任务（setTimeout
）之前执行。这种精细的控制在某些场景下非常有用，比如框架内部的批处理更新。
理解这些，能够让我们在编写异步代码时更有掌控感，不再是“凭感觉”写代码，而是真正理解JS引擎背后的运行逻辑。
