事件循环是单线程JavaScript中实现异步任务调度的核心机制,通过宏任务队列(如setTimeout)和微任务队列(如Promise.then)的交替执行来模拟并发。
JavaScript 是单线程的,不能同时执行两段代码;但又要响应点击、定时器、网络请求等异步操作——事件循环就是解决
这个矛盾的核心机制。它不“并发”,而是靠排队+切换来模拟异步:同步代码走完,立刻检查有没有微任务要跑;微任务清空后,再取下一个宏任务。
setTimeout 是宏任务,Promise.then 是微任务,这是最稳的区分依据区分宏任务和微任务,别记定义,直接看“谁往哪个队列塞任务”。浏览器/Node.js 引擎内部有两套独立队列:macrotask queue 和 microtask queue。你调用的 API 决定了它进哪边:
setTimeout、setInterval、UI 渲染、script 整体、fetch 回调(完成时)、click 事件处理器 → 全进宏任务队列Promise.then/.catch/.finally、queueMicrotask、MutationObserver 回调 → 全进微任务队列process.nextTick 也属微任务,但优先级比 Promise 还高(仅限 Node)哪怕 setTimeout(() => {}, 0) 延迟为 0,它仍是宏任务,一定排在当前所有微任务之后执行。
console.log 顺序总和预期不一样?因为你在写代码时默认按“书写顺序”脑补执行流,但事件循环会把异步部分“挪走排队”。下面这段代码能暴露全部逻辑:
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4);
输出一定是 1 → 4 → 3 → 2。原因:
1 和 4 是同步代码,立刻执行Promise.then 是微任务,当前宏任务(即整个脚本)结束后立刻执行 → 输出 3
setTimeout 是宏任务,得等上一轮事件循环彻底结束(包括微任务清空),才轮到它 → 输出 2
这种“延迟不可控”的现象,不是 bug,是机制使然。想强制某段逻辑在渲染前执行,就用微任务;想等页面更新后再做处理,就得用 setTimeout 或 requestIdleCallback。
微任务不是“马上执行”,而是“当前宏任务末尾立即执行”——这意味着:
Promise.then,它会加入**同一轮微任务队列末尾**,而不是立刻执行(所以能形成链式清空)queueMicrotask,它们都会在当前宏任务结束后按顺序跑完,中间不会穿插任何宏任务或渲染setTimeout 里,就能看到逐帧效果真正难调试的,往往不是“哪个先执行”,而是“为什么我的 Promise 回调没拿到最新 DOM 状态”——答案通常是:你忘了微任务发生在渲染前,而你想读的是渲染后的布局信息。