宏任务和微任务决定JavaScript事件循环执行顺序：同步代码执行完后先清空所有微任务，再执行下一个宏任务；宏任务包括script、setTimeout、用户事件等，微任务包括Promise.then、queueMicrotask等。

宏任务和微任务是 JavaScript 事件循环里两类不同优先级的异步任务，它们决定了代码实际执行的顺序。简单说：同步代码跑完后，先清空所有微任务，再执行下一个宏任务。

宏任务是“一轮循环的主角”

每次事件循环只取一个宏任务来执行，它是调度的基本单位。常见类型包括：

• 整体脚本（标签里的代码本身）
• setTimeout/setInterval 回调
• 用户事件（如 click、input）
• UI 渲染（浏览器环境）
• requestAnimationFrame

宏任务之间互不干扰，每执行完一个，就立刻进入微任务处理阶段。

微任务是“插队的急事”

微任务不参与轮次竞争，而是在当前宏任务结束后、下一个宏任务开始前，一口气全部执行完。常见类型有：

• Promise.then/catch/finally
• queueMicrotask()（显式添加）
• MutationObserver 回调

关键点：如果某个微任务里又调用了 Promise.resolve().then() 或 queueMicrotask()，新任务会加入当前微任务队列，继续执行，直到队列彻底为空。

执行顺序很固定

一个典型的事件循环步骤是：

• 运行当前宏任务中的同步代码
• 遇到 setTimeout → 推入宏任务队列；遇到 Promise.then → 推入微任务队列
• 同步代码执行完毕，立即执行全部微任务（按加入顺序）
• 微任务队列清空后，浏览器可能触发渲染（仅限浏览器环境）
• 从宏任务队列取出下一个任务，重复流程

所以即使 setTimeout(fn, 0) 和 Promise.resolve().then(fn) 同时写，后者一定先执行。

为什么这个区分很重要

它直接影响状态更新时机和 UI 表现。比如：

• 用 Promise.then 处理数据更新，能确保 DOM 变更在渲染前完成
• 用 setTimeout 做延迟或任务切片，避免阻塞主线程
• 误把大量逻辑塞进微任务，可能造成事件循环卡顿（微任务永不中断）

基本上就这些。理解清楚谁先谁后，很多“明明写了却没按预期执行”的问题就迎刃而解了。