任务队列按宿主环境划分专用队列：ui事件入交互队列（高响应优先级）、定时器入延时队列（系统时钟驱动）、网络i/o入网络队列（线程解耦），三者隔离调度、互不干扰。
任务队列中的任务源不是按“执行时机”粗略划分的，而是由宿主环境（浏览器或 Node.js）根据任务类型和触发机制，分发到不同专用队列中。UI 事件、定时器、网络 I/O 这三类，各自归属明确、调度独立，且优先级与执行时机有本质差异。
UI 事件走交互队列，响应用户操作
点击、输入、滚动等用户行为触发的回调，统一进入“交互队列”。这个队列由 UI 线程维护，保证用户操作能被及时响应。它不依赖时间延迟，而是由底层事件系统在检测到输入后立即入队。即使同时发生多个点击，它们也按触发顺序排队，不会被 setTimeout 或 Promise 回调打断。
- 典型来源：click、keydown、input、scroll、resize 等事件监听器
- 注意：连续高频事件（如 mousemove）可能被节流，但入队逻辑仍属该队列
- 浏览器会为该队列保留一定调度优先级，避免界面卡顿
定时器任务归入延时队列，受系统时钟驱动
setTimeout 和 setInterval 的回调不属于“立刻执行”的宏任务，而是由定时器线程监控——当系统时钟到达设定时间点，才将回调推入“延时队列”。这个队列独立于交互队列和网络队列，确保定时精度不受其他任务阻塞（但实际执行仍需等待当前宏任务结束 + 微任务清空）。
- setImmediate（Node.js）和 requestIdleCallback（浏览器）也属于此类，但分属不同专用队列
- 0 毫秒定时器（setTimeout(fn, 0)）并不立即执行，只是尽快排入延时队列末尾
- 多个 setTimeout 共享同一队列，按注册顺序+到期时间共同排序
网络 I/O 回调进入网络队列，由底层线程完成通知
fetch 响应、XMLHttpRequest 完成、WebSocket 消息等，由网络线程处理完毕后，将回调推入“网络队列”。该队列与 UI 线程解耦，避免网络延迟拖慢界面。一旦数据就绪，回调即入队，但实际执行仍需等待当前宏任务结束、微任务清空、甚至 UI 渲染完成之后。
- 注意：Promise.then() 本身是微任务，但 fetch().then() 中的 then 是网络 I/O 完成后才触发的微任务，源头仍是网络队列
- Node.js 中的 fs.readFile 回调走的是 I/O 队列，机制类似，由 libuv 的线程池完成通知
- 跨域或预检失败等异常情况，也会生成对应错误回调，同样进入该队列
三类任务各自隔离、互不干扰，正是这种分类机制让浏览器能在复杂场景下兼顾响应性、定时准确性和 I/O 效率。理解它们的归属，比死记“宏任务有哪些”更能帮你定位异步行为的延迟根源。
