JavaScript事件循环是单线程下异步任务调度的核心机制，由调用栈、宏任务队列和微任务队列协同工作；每轮执行一个宏任务后清空全部微任务，故Promise.then总先于setTimeout执行。
JavaScript事件循环是单线程环境下处理异步任务的核心机制，它决定了代码何时执行、按什么顺序执行——尤其是setTimeout、Promise、用户交互等异步操作，看似“同时发生”，实则严格排队。
事件循环的基本结构：调用栈、任务队列与微任务队列
JS引擎运行时有三个关键部分协同工作：
- 调用栈（Call Stack）：同步代码逐行执行的地方，后进先出。遇到函数调用就压栈，返回就出栈。
-
宏任务队列（Macrotask Queue）：存放定时器回调（
setTimeout、setInterval）、I/O 回调、setImmediate（Node.js）、UI 渲染任务等。 -
微任务队列（Microtask Queue）：存放
Promise.then/catch/finally、queueMicrotask()、MutationObserver等回调。它的优先级高于宏任务。
事件循环每轮只执行一个宏任务，但会在该宏任务结束后，**清空整个微任务队列**（即连续执行所有当前积压的微任务），再取下一个宏任务。
为什么 Promise.then 总比 setTimeout 先执行？
因为 Promise.then 的回调进入微任务队列，而 setTimeout 进入宏任务队列。即使把 setTimeout 设为 0ms，它也要等当前宏任务 + 所有微任务执行完才轮到。
立即学习“Java免费学习笔记（深入）”；
例如：
Promise.resolve().then(() => console.log('micro1'));
setTimeout(() => console.log('macro1'), 0);
Promise.resolve().then(() => console.log('micro2'));
输出一定是：micro1 → micro2 → macro1。
async/await 是怎么参与事件循环的？
async 函数本质是语法糖，内部基于 Promise。每次遇到 await，后面的代码会被包装成微任务推入微任务队列。
-
await Promise.resolve()后的语句，相当于.then()中的内容，属于微任务。 -
await new Promise(resolve => setTimeout(resolve, 0))则会等待下一轮宏任务，因为setTimeout是宏任务。
这解释了为什么多个 await 连续写，不会阻塞主线程，但执行时机仍受微任务调度约束。
实际开发中容易踩的坑
- 误以为 setTimeout(0) 是“立刻执行”：它只是尽快安排进宏任务队列，前面可能还有大量微任务或长同步代码挡着。
- 在 Promise.then 里写大量同步逻辑，导致 UI 卡顿：虽然进了微任务队列，但它仍是在主线程同步执行的——微任务不是“多线程”，只是调度优先级高。
-
DOM 更新时机混乱：
Promise.then在渲染前执行；setTimeout在渲染后（浏览器通常在宏任务之间做一次渲染）。想确保 DOM 已更新，可用queueMicrotask或requestAnimationFrame（后者更接近渲染时机）。
理解事件循环不是为了背流程图，而是写出可预期、不掉链子的异步逻辑。
