微任务总在宏任务前执行，因事件循环规定每个宏任务后必须清空全部微任务队列；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” 面板可直观查看当前微任务/宏任务队列状态
Promise、async、setTimeout、甚至 React 的更新调度，都建立在这个模型之上。漏掉它，等于在黑盒里调代码。 
