事件循环中，每次执行完一个宏任务后立即连续清空整个微任务队列，之后才取下一个宏任务；Promise.then、queueMicrotask、MutationObserver回调属于微任务，setTimeout、requestIdleCallback等属于宏任务。
事件循环的核心机制：宏任务和微任务怎么排队
JavaScript 是单线程的，靠事件循环（Event Loop）协调同步代码、异步回调与渲染。关键不是“谁先执行”，而是“谁在哪个队列里、什么时候被清空”。setTimeout、setInterval、I/O 回调属于宏任务（macrotask），而 Promise.then、MutationObserver、queueMicrotask 属于微任务（microtask）。
每次执行完一个宏任务后，引擎会**立即、连续地清空整个微任务队列**，直到为空；之后才取下一个宏任务。这意味着：
-
Promise.resolve().then(() => console.log(1))一定比setTimeout(() => console.log(2), 0)先输出 - 连续 5 个
queueMicrotask会一次性执行完，中间不会穿插渲染或下一个宏任务 - 如果某个微任务又注册了新的微任务（比如在
then里再调Promise.resolve().then），它会被追加到当前微任务队列末尾，仍会在本轮清空
哪些操作会触发微任务？常见误判点
开发者常以为“所有异步回调都是微任务”，其实不然。只有明确由 JS 引擎规范定义为微任务源的操作才会进微任务队列。以下操作**确定入微任务队列**：
-
Promise.prototype.then/.catch/.finally的回调函数（即使 Promise 已 resolve/reject） -
queueMicrotask(callback)—— 明确、轻量、无兼容性问题的微任务入口 -
MutationObserver的回调（DOM 变更观察完成时）
以下操作**不是微任务**，容易误判：
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
process.nextTick（Node.js 特有，优先级高于微任务，但仅限 Node） -
Object.observe（已废弃，从未进入标准） -
requestIdleCallback是宏任务，不是微任务
浏览器渲染和事件循环的关系
渲染不是事件循环的“任务类型”，而是浏览器在特定时机主动插入的步骤。主流浏览器（Chrome/Firefox/Safari）遵循大致相同的节奏：
- 执行一个宏任务（如点击事件处理函数）
- 清空全部微任务
- **检查是否需要渲染**：若 DOM 有变更、且距上次渲染 ≥ 约 16ms（即未超 60fps 预算），则进行样式计算、布局、绘制、合成
- 从宏任务队列取下一个（可能为空，则等待新事件）
这意味着：setTimeout(() => { /* 修改 DOM */ }, 0) 不会立刻渲染；要强制让修改生效并触发重绘，得等下一轮宏任务+渲染周期。如果想“在本次更新后马上读取布局”，得用 requestAnimationFrame —— 它的回调在渲染前执行，但本身是宏任务。
实际调试技巧：如何观察当前任务队列状态
浏览器没有直接暴露“当前微任务队列长度”的 API，但可以通过组合手段验证行为：
- 用
console.time+ 多层Promise.then嵌套，看输出顺序是否严格串行 - 在
setTimeout开头打日志，再在Promise.then打日志，确认后者总在前者之前 - 遇到“DOM 更新没立刻生效”，先检查是不是把操作写在了微任务里（如
Promise.then），而期望它触发同步渲染 —— 实际上它只是保证在当前宏任务后执行，不保证渲染时机
真正难调试的，往往不是“哪个先执行”，而是“你以为的‘同步更新’其实是异步的 DOM 应用，而你又在它完成前就读取了 offsetTop 或 getComputedStyle”。
