事件循环是单线程下协调任务执行的机制，按“主线程→微任务→宏任务”顺序调度，每次宏任务后清空微任务队列，再取下一个宏任务。
事件循环不是 JavaScript 引擎的“调度器”，而是单线程下协调任务执行的机制
JavaScript 是单线程语言，但能处理异步操作（如 setTimeout、fetch、用户点击），靠的不是多线程，而是事件循环（Event Loop）。它不负责“创建”任务，只按固定规则从任务队列中取出任务执行——主线程空闲时，才去检查微任务队列和宏任务队列。
宏任务和微任务的执行优先级决定实际输出顺序
常见误解是“先执行所有 setTimeout，再执行所有 Promise.then”，其实不然。每次宏任务执行完，会**清空当前轮次的微任务队列**，再取下一个宏任务。
典型执行顺序：
- 同步代码（宏任务起点）
- 遇到
Promise.resolve().then()→ 推入微任务队列 - 遇到
setTimeout(() => {}, 0)→ 推入宏任务队列（下一轮） - 同步代码结束 → 立即执行所有已排队的微任务（哪怕有多个
then） - 微任务清空后 → 取出下一个宏任务（如
setTimeout回调）
示例：
立即学习“Java免费学习笔记（深入）”；
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
queueMicrotask 和 Promise.then 的行为几乎一致，但更轻量
queueMicrotask 是显式插入微任务的标准 API，语义比 Promise.resolve().then() 更直接，且无 Promise 构造开销。两者都保证在当前宏任务结束后、下一个宏任务开始前执行。
注意点：
-
queueMicrotask不兼容 IE 和旧版 Safari（需检查目标环境） - 嵌套调用
queueMicrotask会继续追加到本轮微任务队列末尾，不会立即执行 - 不要用它替代
setTimeout(fn, 0)来“让出主线程”——微任务仍会阻塞渲染，真正让出应选宏任务（如setTimeout或requestIdleCallback）
为什么 await 后的代码不总在下一轮微任务执行？
await 并非“自动加 Promise.then”，它会把后续代码包装成微任务，但前提是等待的是一个“thenable”或 Promise。如果 await 123，等价于 await Promise.resolve(123)，所以后续仍进微任务；但如果 await 的是同步完成的 Promise（比如已 resolve 的缓存结果），V8 等引擎可能优化为“不真正挂起”，导致表现像同步代码——这属于实现细节，不可依赖。
可靠写法：
- 想确保异步，显式返回
Promise.resolve().then(...)或queueMicrotask(...) - 调试时别只看
console.log，用performance.now()或 DevTools 的 “Tasks” 跟踪真实调度时机 - 注意 Node.js 和浏览器的微任务排队策略略有差异（如 Node.js 的
process.nextTick优先级高于Promise.then）
事件循环本身没有“魔法”，它只是严格遵循“主线程 → 微任务 → 宏任务”的三段式节奏。真正容易出错的，是误判哪些操作进了哪个队列，以及忽略了浏览器渲染帧与任务队列的交互。
