宏任务队列是宿主环境维护的异步回调容器，每轮事件循环仅取首个任务执行；其来源包括script、setTimeout、I/O、UI事件等，执行完后才清空微任务队列，不插队、不嵌套。

宏任务队列不是“一个队列”，而是一组由宿主环境（浏览器或 Node.js）维护的、按插入顺序排队的异步回调容器，它本身不主动调度，只等待事件循环在每轮中取出首个任务执行。

宏任务的来源与触发方式

宏任务由外部运行时环境发起，代表一次相对完整的、可被用户感知的执行单元。它不是 JS 引擎直接创建的，而是通过宿主 API 注册后交由底层线程或系统事件驱动触发：

• script 全局代码：页面加载时整个 JS 文件的同步执行，是第一个宏任务
• 定时器类：setTimeout、setInterval 的回调，在指定延迟后被推入宏任务队列
• I/O 类操作：fetch 响应、XMLHttpRequest 完成、Node.js 中的 fs.readFile 回调
• UI 相关事件：click、input、scroll 等用户交互事件处理函数
• 渲染帧：浏览器在每帧末尾进行 UI 渲染（requestAnimationFrame 属于特殊宏任务，但执行时机早于普通宏任务）
• 消息通信：postMessage、MessageChannel 的 onmessage 回调

宏任务队列的调度规则

事件循环每轮仅从宏任务队列头部取出一个任务执行，且该任务必须完整执行完毕（包括其内部所有同步代码和嵌套调用），才进入下一阶段：

• 执行过程中产生的新宏任务（如另一个 setTimeout）会被追加到队列尾部，不会插队
• 宏任务之间不嵌套执行，即 A 宏任务执行中触发 B 宏任务，B 不会立即执行，而是等 A 完全结束、微任务清空后再轮到
• 浏览器环境下，宏任务执行后通常会触发一次渲染（若 DOM 有变更），但该渲染不是宏任务，而是事件循环隐式阶段

与微任务队列的关键区别

宏任务队列和微任务队列是两个独立结构，调度优先级与执行节奏完全不同：

• 微任务在每个宏任务结束后立即连续执行全部，中间不穿插任何宏任务或渲染
• 宏任务每次只取一个，执行完才检查微任务队列；而微任务队列一旦开始执行，就会清空到底（包括执行中动态加入的新微任务）
• Promise.then 不进宏任务队列，MutationObserver 回调也不进——它们属于 JS 引擎控制的微任务机制，与宿主无关

实际开发中的典型影响

理解宏任务队列行为，能解释很多看似反直觉的执行顺序问题：

• 多个 setTimeout(fn, 0) 并不保证立即执行，它们按注册顺序排队，且需等前序宏任务+全部微任务完成
• 用户点击按钮后更新 DOM，再 setTimeout 读取该 DOM，往往读不到最新值——因为渲染尚未发生，而 setTimeout 是下一个宏任务
• 避免在单个宏任务中做大量同步计算（如长循环），否则会阻塞后续宏任务（包括用户交互响应、动画帧）