宏任务执行完后立即清空所有微任务，再取下一个宏任务；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+ 均支持）。
立即学习“Java免费学习笔记（深入）”；
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就用，别硬塞进微任务
