事件循环不直接调度Web API，而是为回调提供统一调度时机；Web API由浏览器内核独立模块处理，JS引擎仅发起调用并注册回调；异步操作完成后按类型将回调放入微任务队列（如Promise）或宏任务队列（如setTimeout），事件循环在调用栈清空后先执行全部微任务再执行一个宏任务，确保回调适时执行且不阻塞UI。
事件循环机制本身不直接调度 Web API 接口，而是为 Web API 的回调执行提供统一的调度时机和顺序保障。
Web API 不在 JS 引擎内运行
像 fetch、XMLHttpRequest、setTimeout 这类 Web API，实际由浏览器内核（如 Blink 或 WebKit）的独立模块处理，JS 引擎只负责发起调用并注册回调。这些 API 在后台线程或系统级模块中执行，不占用主线程，也不进入调用栈。
- 网络请求走 Network 模块，完成后再通知 JS 主线程
- 定时器由 Timer 模块维护，到期后触发回调入队
- DOM 事件由 DOM binding 模块监听，触发后把处理函数推入任务队列
事件循环决定“何时执行回调”
当 Web API 完成异步操作（比如 fetch 返回响应），它不会立刻执行你写的 .then() 或 onload 回调，而是按类型把回调放入对应的任务队列：
- Promise.then/catch/finally → 微任务队列（Microtask Queue）
- setTimeout/setInterval、fetch 的 then 链外层回调 → 宏任务队列（Macrotask Queue）
- MutationObserver → 微任务队列
事件循环持续检查：调用栈清空后，先清空全部微任务，再取一个宏任务执行——这就确保了接口响应的回调总在合适时机被调度，既不抢在同步代码前，也不被无限延迟。
避免阻塞 UI，支撑真实交互场景
用户点击按钮触发 API 调用时，主线程能立刻响应后续操作（比如显示 loading、更新按钮状态），而不用等接口返回。这是因为：
- 发起请求是同步的（瞬间完成），真正耗时的网络过程交由浏览器底层处理
- 回调被排队等待，事件循环在空闲时才拉取执行
- 微任务优先机制让 Promise 链能快速衔接，适合做状态更新、错误链式处理
影响接口使用方式的关键细节
理解事件循环能帮你写出更可预测的逻辑：
- 多个
fetch().then()会作为微任务连续执行，中间不插入渲染或用户事件 -
setTimeout(() => {}, 0)是宏任务，总会排在当前所有微任务之后 - 想让 DOM 更新（如显示加载中）在请求发出后立刻生效，要确保更新语句在
fetch调用之前或之后立即同步执行，而不是依赖回调时机
