事件循环不处理ajax请求，仅调度已入队的回调；网络请求由浏览器web api在后台线程完成，响应后按微任务（如fetch().then）或宏任务（如xmlhttprequest.onload）分类入队，再由事件循环依序执行。
JavaScript 事件循环本身不直接处理 Ajax 请求或回调，它只负责调度已进入任务队列的回调函数；真正的网络请求由浏览器的 Web API（如 fetch 或 XMLHttpRequest）在后台线程中发起和完成，完成后才将对应的回调推入任务队列等待执行。
异步请求如何“绕过”主线程？
浏览器内核为网络、定时器、DOM 事件等提供了独立于 JS 主线程的系统级能力（Web API）。当你调用 fetch() 或 new XMLHttpRequest() 时，JS 引擎只是把请求配置交给这些底层模块，立刻返回（不阻塞），继续执行后续同步代码。
- 请求实际由浏览器的网络线程发起，与 JS 执行完全解耦
- 响应到达后，浏览器判断该回调属于微任务（如
fetch().then()）还是宏任务（如setTimeout回调），再放入对应队列 - 事件循环只在当前调用栈为空时，按“先清空所有微任务 → 取一个宏任务 → 再清空微任务…”的规则持续循环
回调函数怎么进队列？分两类看
微任务回调（优先执行）：
Promise.then/catch/finally、queueMicrotask()、MutationObserver 的回调，响应完成后立即被加入微任务队列。下一轮事件循环开始前，它们会被一次性全部执行完。
宏任务回调（次优先）：
XMLHttpRequest.onreadystatechange（当 readyState === 4 时）、setTimeout、setInterval、I/O 事件等，被放入宏任务队列，每次事件循环只取一个执行。
例如：fetch().then(...) 的回调是微任务；而用 XMLHttpRequest 并监听 onload，其回调是宏任务（取决于浏览器实现，但主流浏览器将其作为宏任务处理）。
常见误区：Promise 不是“让代码变异步”，而是“统一异步流程”
Promise 构造函数里的执行器（executor）是同步运行的：
new Promise(resolve => {
console.log('1'); // 立即输出
resolve();
console.log('2'); // 立即输出
}).then(() => console.log('3')); // '3' 在本轮同步代码结束后、微任务阶段输出
// 输出顺序：1 → 2 → 3
所以 fetch() 返回 Promise，不是因为它内部用了 Promise，而是浏览器在响应就绪后，自动调用 resolve —— 这个 resolve 触发了微任务入队。
调试建议：用 DevTools 的 Network 和 Performance 面板定位瓶颈
如果异步请求“卡住”或回调迟迟不执行，大概率不是事件循环问题，而是：
- 网络延迟高、服务端响应慢（查 Network 面板的 Timing）
- 主线程被大量同步计算阻塞（如长循环、复杂渲染），导致事件循环无法及时轮转（查 Performance 面板的 Main 线程火焰图）
- 多个微任务链过长（比如连续几十次
then嵌套），虽不阻塞页面，但会延迟后续宏任务（如 UI 更新、用户点击）
真正影响响应感的，往往不是回调“进队列”的时机，而是它“被执行”时主线程是否空闲。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
