宏任务队列由宿主环境（浏览器/Node.js）的多线程协同维护，是事件循环按FIFO顺序读取的逻辑队列，JS引擎仅执行不管理；其任务来源包括定时器、DOM事件、I/O完成等，每轮事件循环只执行一个宏任务，随后清空全部微任务。
宏任务队列由浏览器或运行时环境（如 Node.js）的事件循环系统统一维护，不是 JavaScript 引擎直接管理的数组，而是一个由底层线程（如定时器线程、网络线程、UI 渲染线程等）协同写入、事件循环按序读取的 FIFO（先进先出）结构。
宏任务的来源与入队时机
宏任务并非由 JS 代码“主动 push”，而是由外部环境在特定条件满足后，将回调函数作为任务插入宏任务队列：
- setTimeout / setInterval：由定时器线程计时完成，触发后将回调加入宏任务队列（注意：不是到期立刻执行，而是“到期后尽快入队”）
- DOM 事件（如 click、input）：由 UI 线程捕获并分发，事件处理函数被推入宏任务队列
- setImmediate（Node.js）或 requestAnimationFrame（浏览器）：分别由 Node 的事件循环阶段或浏览器渲染管线调度后入队
- I/O 操作完成（如 fetch 响应、fs.readFile）：由网络线程或文件线程通知后，将 resolve 回调作为宏任务入队（注意：fetch.then 是微任务，但 fetch 本身触发的响应处理属于宏任务层级）
- script 标签整体执行：每个顶层脚本块本身就是一个宏任务（即初始执行上下文）
队列的独立性与调度规则
宏任务队列是逻辑上独立于微任务队列的结构，它不参与“本轮循环”的即时清空：
- 事件循环每轮只从宏任务队列中取出一个任务执行（哪怕队列里有 10 个 setTimeout 回调，也只执行第一个）
- 该宏任务执行完毕后，会立即清空当前所有微任务**（Promise.then、queueMicrotask 等），再进行 DOM 渲染（如果需要），最后才回到宏任务队列取下一个
- 不同类型的宏任务可能分布在不同物理队列中（如 Chrome 将 timer、I/O、UI 任务分属不同队列），但事件循环按优先级和规范顺序统一调度，对开发者表现为单个逻辑宏任务队列
谁在维护？关键不在 JS 引擎
JavaScript 引擎（如 V8）只负责执行已入栈的同步代码和回调函数；宏任务队列的实际维护者是宿主环境：
立即学习“Java免费学习笔记（深入）”；
- 浏览器中：由渲染进程中的多个工作线程（timer thread、network thread、compositor thread 等）协作写入，主线程的事件循环只负责读取和调度
- Node.js 中：由 libuv 库管理多线程池，完成异步操作后将回调注册为宏任务，交由事件循环的各个阶段（timers、I/O callbacks、check 等）消费
- JS 引擎本身不创建、不排序、不延迟**宏任务——它只响应已排好序的任务
常见误区澄清
宏任务队列不是“随时可读写的数组”，它的行为受规范约束且不可直接访问：
- 你无法用代码获取宏任务队列长度，也没有类似 queueMicrotask 的 queueMacrotask API
- setTimeout(fn, 0) 不等于“立刻执行”，而是“尽可能快地安排一次宏任务”，实际执行时机取决于当前队列状态和浏览器节流策略
- 多个 setTimeout(fn, 0) 调用会按调用顺序入队，但它们的执行仍需等待前一个宏任务结束 + 所有微任务清空 + 可能的渲染帧
