现代浏览器事件循环采用多队列分级机制：微队列（最高优先级，含promise/mutationobserver）、交互队列（次高，含click/scroll）、延时队列（中等，含settimeout）、网络队列及渲染相关队列，各队列按类型隔离、优先级执行，由事件循环协议协调调度。
任务队列不是单一队列，而是由多个按类型划分、优先级分层的专用队列组成的系统。浏览器通过事件循环协调这些队列的执行，而非简单地用一个 FIFO 数组来管理所有异步任务。
任务按类型隔离到不同队列
W3C 规范明确要求：同类型任务必须进入同一队列，不同类型任务必须进入独立队列。这种设计避免低优先级任务（如网络回调）阻塞高响应需求任务（如用户点击）。
- 微队列（Microtask Queue）：仅存放 Promise.then/catch/finally 回调、MutationObserver 回调。每次事件循环末尾，主线程空闲时必须清空该队列才可进入下一阶段。
- 交互队列（Interaction Queue）：专用于用户输入事件，如 click、scroll、keydown。Chrome 将其设为宏任务中最高优先级，确保 UI 响应及时。
- 延时队列（Timer Queue）：存放 setTimeout/setInterval 回调。实际执行时间可能晚于设定延迟，因受队列优先级和主线程负载影响。
- 网络队列（Network Queue）：承载 fetch、XMLHttpRequest 的 onload/onerror 回调。与渲染无关，可被调度器延后执行。
- 渲染相关队列：如 CSS 动画帧回调（requestAnimationFrame）、样式计算与布局任务，通常由合成线程或渲染管线驱动，不直接暴露给 JS。
底层数据结构以高效插入/移除为核心
各队列内部普遍采用链表或环形缓冲区实现，而非普通数组。原因在于频繁的入队（enqueue）和出队（dequeue）操作需 O(1) 时间复杂度。
- 微队列在 V8 引擎中由 MicrotaskQueue 类管理，底层是双向链表，支持快速头插尾删；
- 宏任务队列（如延时队列）在 Blink 渲染引擎中使用基于时间堆（timing heap）的优先队列，便于按到期时间快速提取下一个定时任务；
- 交互队列则倾向使用无锁队列（lock-free queue），减少多线程（如输入线程向主线程投递事件）同步开销。
事件循环驱动多队列协同
事件循环本身不是队列，而是一个调度协议。它按固定阶段依次检查并消费各队列，顺序为：
- 执行当前宏任务（如一个 click 回调）；
- 清空微队列（全部 Promise/MutationObserver 回调）；
- 执行一次渲染（若需要，包括样式计算、布局、绘制、合成）；
- 从宏任务队列中选取下一个任务（优先选交互队列，再轮询其他）；
注意：渲染阶段并非每次循环都发生，仅当 DOM 或样式变更且未被节流时触发。这使得动画帧与 JS 执行解耦，也解释了为何连续多次 DOM 修改只触发一次重排。
与浏览器多进程架构深度绑定
任务队列的归属和投递依赖进程间协作：
- 用户点击由浏览器主进程的输入线程捕获，经 IPC 发送给对应渲染进程的交互队列；
- fetch 请求由网络进程处理完毕后，通过 IPC 将响应数据与回调任务注入渲染进程的网络队列；
- requestAnimationFrame 回调由合成线程根据刷新率生成，并推入渲染进程的动画队列，再由事件循环调度执行。
这种跨进程任务投递机制，使队列行为既受 JS 单线程限制，又依托系统级资源调度能力，形成兼顾响应性与稳定性的执行模型。
