事件循环是单线程下保障页面流畅的机制而非提速工具；因dom操作需避免竞态，js天然单线程，依赖浏览器多线程协同；宏任务执行后必须清空全部微任务，微任务可递归追加但不触发渲染，而宏任务间可能渲染。
事件循环不是“让JS变快”的魔法，而是单线程下不卡死页面的生存策略。它不提速，但保流畅——这是理解它的起点。
为什么必须是单线程？
JavaScript 从设计之初就只为操作 DOM。如果允许多线程并发改 DOM，结果将不可预测：比如两个线程同时删同一个元素，或一个加样式、一个清样式，浏览器根本无法协调。所以 JS 引擎线程天然单线程，所有代码排队执行。
但用户不能等：点击要响应、接口要加载、动画要流畅。于是浏览器用多线程（定时器线程、网络线程、渲染线程等）分担耗时工作，JS 主线程只负责“调度”和“处理回调”，这就是事件循环存在的根本原因。
宏任务和微任务，不只是分类，是执行节奏
宏任务和微任务不是并列关系，而是严格嵌套的优先级结构：
- 每个宏任务执行完后，**必须立即清空当前产生的全部微任务**，一个不留
- 微任务中产生的新微任务，会追加到本轮队列尾部，仍属于“本轮清空”范围
- 微任务执行期间不会触发 UI 渲染；而宏任务之间，浏览器可能进行一次渲染（取决于刷新频率，通常每 16ms 一次）
- 常见宏任务：整体 script、setTimeout、setInterval、I/O、DOM 事件回调、UI 渲染
- 常见微任务：Promise.then/catch/finally、async/await 后续代码、queueMicrotask、MutationObserver
执行流程，三步闭环不能跳
事件循环不是“取一个宏任务→执行→取下一个”，而是固定四步循环：
- 同步代码全部执行完毕（调用栈归零）
- 检查微任务队列，**一次性执行完所有现存微任务**（包括过程中新增的）
- 从宏任务队列头部取出一个宏任务执行
- （浏览器环境）可能触发一次渲染，然后回到第一步
这个闭环决定了：Promise 回调永远比 setTimeout 先输出；await 后面的语句本质是微任务，不是“等完再继续同步执行”。
面试高频陷阱与验证方法
考题常以多层嵌套 Promise、setTimeout 和 async/await 混合出现。破解关键是“纸上模拟”：
- 画三栏：同步执行流、宏任务队列、微任务队列
- 逐行扫描，遇到同步代码直接写入执行流；遇到 setTimeout 推入宏队列；遇到 Promise.then 推入微队列
- 同步块结束后，先填满微任务栏（直到清空），再取一个宏任务，重复
- 特别注意：async 函数内部 await 之后的代码，等价于 Promise.then，属于微任务
不复杂但容易忽略。
