JavaScript主线程不阻塞页面的根本原因是事件循环调度机制：先执行同步代码，再清空微任务队列，最后执行一个宏任务；耗时操作由浏览器其他线程处理，完成后仅向任务队列插入回调。
异步代码不阻塞页面，根本原因不是 JavaScript 自己“会异步”，而是它把耗时操作交出去做，自己只管执行和调度——事件循环就是这个调度员。
主线程只做三件事：执行、清微任务、取宏任务
JavaScript 主线程永远只干这三件事，而且严格按顺序：
- 先跑完所有同步代码（压栈→执行→出栈）
- 同步代码一结束，立刻检查微任务队列（Promise.then、catch、finally、queueMicrotask 等），全部执行完，一个不留
- 再从宏任务队列里拿一个（比如 setTimeout 回调、DOM 事件、fetch 响应回调），执行它
- 执行完这个宏任务后，又回到第二步：先清空微任务，再取下一个宏任务
耗时操作根本不在主线程里等
像 setTimeout、fetch、addEventListener 这些异步操作，一触发就立刻交给浏览器的其他模块处理：
- 定时器由独立的 Timer Thread 管理
- 网络请求走 Network I/O 线程（底层用 libuv 或系统 API）
- DOM 渲染由 GUI/Render Thread 负责
- 这些线程并行运行，和 JS 主线程互不干扰
- 它们做完后，只是往对应的任务队列里“丢一个回调函数”，并不直接打断 JS 执行
用户操作依然能被响应
页面不卡，是因为用户交互（点击、滚动、输入）产生的事件回调也进宏任务队列，和其他 setTimeout、fetch 回调一样排队。只要主线程没被长同步任务霸占，事件循环就能及时取出这些 UI 相关的宏任务来执行：
立即学习“Java免费学习笔记（深入）”；
- 哪怕有 10 个 setTimeout(0) 在排队，每个回调都很快，主线程仍能穿插处理 click 事件
- 如果某个 Promise 微任务执行太久（比如里面写了死循环），它会阻塞后续所有微任务和下一个宏任务——所以微任务里别写重逻辑
- 真正导致卡顿的，从来不是异步本身，而是同步代码太长，或者微任务失控
简单看一段代码怎么流动
这段代码执行顺序清晰体现了事件循环的节奏：
console.log('1');setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
输出是 1 → 4 → 3 → 2。因为：
- '1' 和 '4' 是同步代码，立刻执行
- Promise.then 进入微任务队列，同步代码一完马上执行 → '3'
- setTimeout 回调进宏任务队列，要等当前宏任务（整个脚本）彻底结束、且微任务清空后才轮到 → '2'
