17370845950

宏任务执行完后立即清空所有微任务，再取下一个宏任务；script是初始宏任务，微任务不触发新循环，只在当前宏任务末尾执行；queueMicrotask比setTimeout(0)更精准可控，但需防微任务无限递归导致卡死。

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

JavaScript事件循环每次只取一个宏任务执行，执行完后**立刻清空当前所有微任务**，再取下一个宏任务。这个“先清微、再取宏”的固定节奏，就是你看到 Promise.then 总比 setTimeout 先打印的根本原因。

常见错误现象：
写了一堆 setTimeout(() => console.log('a'), 0) 和 Promise.resolve().then(() => console.log('b'))，却惊讶地发现所有 b 都在所有 a 前面——这不是 bug，是机制。

• script 整体（即页面加载时的顶层同步代码）本身就是一个宏任务
• 微任务不会触发新一轮事件循环，只在当前宏任务“收尾”时插入执行
• 嵌套的 Promise.then 或 queueMicrotask 会继续加入微任务队列，直到队列为空才让出控制权

哪些 API 属于宏任务，哪些属于微任务？别靠猜，记清单

浏览器和 Node.js 环境下，分类基本一致，但有细微差别（比如 process.nextTick 是 Node.js 特有微任务）。实际开发中，最常混淆的是 setTimeout 和 Promise.then 的优先级，以及 queueMicrotask 这个明确暴露微任务入口的 API。

• 典型宏任务：setTimeout、setInterval、setImmediate（Node.js）、I/O 回调（如 fetch().then 的响应处理）、UI 渲染、用户事件回调（如 click）
• 典型微任务：Promise.then/catch/finally、queueMicrotask、MutationObserver 回调；Node.js 中还有 process.nextTick
• async/await 本质是 Promise 语法糖，所以 await 后面的代码会被包装进微任务

用 queueMicrotask 替代 setTimeout(fn, 0) 更精准

很多人用 setTimeout(fn, 0) 模拟“下一轮”，但这是宏任务，中间可能被 UI 渲染、其他定时器或事件打断。而 queueMicrotask 是标准微任务 API，语义清晰、时机确定、无兼容性风险（Chrome 69+、Firefox 71+、Safari 15.4+、Node.js 11.0+ 均支持）。

console.log('start');
queueMicrotask(() => console.log('micro'));
setTimeout(() => console.log('macro'), 0);
console.log('end');
// 输出：start → end → micro → macro

• 不要用 setTimeout(fn, 0) 实现“立即但不阻塞”，它不立即，只是“尽快下一个宏任务”
• queueMicrotask 是目前最轻量、最可控的微任务调度方式，比手动 new Promise 更直白
• 注意：它不能替代 requestIdleCallback 这类面向帧率的调度，微任务仍会抢占主线程，不适合大量计算

容易踩的坑：微任务无限递归导致页面卡死

微任务队列会在当前宏任务结束后**一次性全部执行完**，如果某个微任务又往队列里加新的微任务（比如在 Promise.then 里又 resolve 一个 Promise），就可能形成无限循环，JS 主线程彻底无法进入下一个宏任务，页面假死。

let i = 0;
Promise.resolve().then(() => {
  console.log(++i);
  if (i < 10) Promise.resolve().then(arguments.callee); // ❌ 危险！
});

• 这种模式在旧代码或某些状态管理逻辑中容易出现，尤其配合重试、轮询等场景
• Node.js 中 process.nextTick 同样危险，且优先级略高于 Promise.then
• 真正需要节流或延迟时，该用 setTimeout 就用，别硬塞进微任务

微任务不是“更快的 setTimeout”，它是事件循环里一个有严格边界和退出条件的执行阶段。混淆这点，轻则输出顺序错乱，重则阻塞渲染甚至卡死主线程。