JavaScript事件循环核心是“一次宏任务+全部微任务”的循环；同步代码入调用栈，异步回调由宿主环境按类型分入宏/微任务队列，微任务总优先于宏任务执行。
JavaScript 的事件循环（Event Loop）是它处理异步任务的核心机制，让单线程的 JS 能够不阻塞地执行代码。它不是浏览器或 Node.js 的特性，而是 JavaScript 运行时（如 V8 引擎）与宿主环境协作形成的调度模型。
调用栈、任务队列和事件循环三者怎么配合？
JS 执行时，同步代码压入调用栈，执行完就弹出；遇到异步操作（比如 setTimeout、fetch、Promise.then），它们不会立刻执行回调，而是由宿主环境（浏览器/Node）接管，等条件满足后把回调函数放入对应的任务队列：
-
宏任务队列（Macrotask Queue）：存放
setTimeout、setInterval、I/O、UI 渲染等回调 -
微任务队列（Microtask Queue）：存放
Promise.then/catch/finally、MutationObserver、queueMicrotask的回调
事件循环每轮先清空当前调用栈，然后**优先执行所有微任务**（直到微任务队列为空），再取一个宏任务执行——这个“一次宏任务 + 全部微任务”的循环就是基本单位。
为什么 Promise.then 总比 setTimeout 快？
因为 Promise.then 的回调进入微任务队列，而 setTimeout 进入宏任务队列。即使设为 setTimeout(fn, 0)，它也要等当前宏任务结束、所有微任务跑完后才轮到。
立即学习“Java免费学习笔记（深入）”；
例如：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出顺序：1 → 4 → 3 → 2
这里 1 和 4 是同步代码；3 是微任务，紧接在同步代码后执行；2 是下一轮宏任务，排在最后。
Node.js 和浏览器的事件循环有啥区别？
整体模型一致，但 Node.js 把宏任务细分为多个阶段（timers、pending callbacks、idle/prepare、poll、check、close callbacks），每个阶段有自己的队列。比如 setImmediate 在 check 阶段执行，process.nextTick 甚至比微任务还优先（它不属于标准事件循环，但会插在当前操作末尾）。
浏览器没这些阶段划分，更简单直接：宏任务 → 微任务 → 宏任务……
实际开发中要注意什么？
理解事件循环能帮你避开常见陷阱：
- 不要依赖
setTimeout(..., 0)来“让出主线程”，用queueMicrotask或Promise.resolve().then更可靠 - 大量微任务（如连续 1000 个
Promise.then）会阻塞渲染和用户交互，可考虑分批用setTimeout拆开 -
await后的代码本质是微任务，所以async function内部的同步逻辑仍按微任务时机执行
基本上就这些。事件循环不复杂，但容易忽略微任务的“即时性”和宏任务的“延迟性”带来的行为差异。
