为什么理解Javascript的微任务与宏任务队列很重要？

微任务总在宏任务前执行，因事件循环规定每个宏任务后必须清空全部微任务队列；script是首个宏任务，promise.then、queueMicrotask属微任务，setTimeout属宏任务。

微任务和宏任务的执行顺序直接决定代码输出结果

你写的 Promise.then 为什么总在 setTimeout 前面打印？不是因为“写得早”，而是因为事件循环强制规定：每个宏任务执行完，必须立刻清空全部微任务队列，之后才取下一个宏任务。这意味着哪怕你在 setTimeout 回调里又创建了 Promise，它的 .then 也会插队到当前宏任务结束后的第一时间执行，而不是等下一轮 setTimeout。

• 常见错误现象：以为“先注册就先执行”，结果 setTimeout(() => console.log(1), 0) 被 Promise.resolve().then(() => console.log(2)) 稳稳压在后面
• 真实执行链：同步代码 → 所有微任务（Promise.then、queueMicrotask）→ ui 渲染 → 下一个宏任务（setTimeout、setInterval）
• 关键点：script 标签整体就是第一个宏任务，别忽略它

用错队列会导致 UI 卡死或渲染异常

微任务优先级高是双刃剑。如果在 queueMicrotask 或 Promise.then 里递归触发自己，就会形成“微任务风暴”——主线程持续被占，浏览器没机会做 UI 渲染，页面看起来完全冻结。

• 典型翻车场景：用 queueMicrotask 实现无限轮询，忘了加退出条件
• 替代方案：想“让出主线程”给渲染，改用 setTimeout(fn, 0) 或 requestAnimationFrame
• 性能影响：连续 100 个微任务可能比 1 个耗时 16ms 的同步计算更伤体验（因为阻塞渲染帧）

queueMicrotask(() => {   console.log('tick');   // ❌ 危险！没有终止条件，会撑爆调用栈   queueMicrotask(arguments.callee); });

不同环境对“微任务”的定义不完全一致

node.js 和浏览器对任务优先级的处理有细微但关键的差异。比如 process.nextTick 在 Node.js 中比 Promise.then 还快，但在浏览器里根本不存在；而 requestAnimationFrame 是浏览器特有宏任务，和渲染强绑定，node.js 不支持。

• 跨环境兼容性陷阱：依赖 process.nextTick 的逻辑在浏览器中会报错 ReferenceError
• 推荐写法：浏览器项目统一用 Promise.resolve().then 或 queueMicrotask（注意检查兼容性）
• 兼容性提醒：queueMicrotask 在 IE 和旧版 safari 中不可用，需 fallback 到 Promise.resolve().then

调试异步逻辑时，队列模型是唯一可靠依据

当你看到“明明 fetch 请求发出去了，但 dom 更新却延迟了”，问题往往不在网络，而在你把更新逻辑放在了错误的任务队列里。现代 API 如 MutationObserver 是微任务，setTimeout 是宏任务，它们插入的位置决定了是否能“赶在下一帧渲染前完成更新”。

立即学习“Java免费学习笔记（深入）”；

• 实际场景：想确保 DOM 变更后立即测量尺寸，用 queueMicrotask 比 setTimeout 更稳妥
• 容易忽略的细节：async/await 函数体内部的代码属于当前宏任务，但 await 后面的语句会被包装进微任务
• 调试建议：chrome DevTools 的 “Event Loop” 面板可直观查看当前微任务/宏任务队列状态

微任务与宏任务不是概念游戏，它是 javaScript 异步行为的底层骨架——所有 Promise、async、setTimeout、甚至 react 的更新调度，都建立在这个模型之上。漏掉它，等于在黑盒里调代码。