事件循环本身不会阻塞，所谓“阻塞”实为同步代码执行过久导致调用栈长期不空，使微任务、宏任务及ui渲染无法及时执行；常见原因包括大数组遍历、同步dom操作、未节流事件处理器等。
事件循环中所谓“阻塞”，不是指 JavaScript 主动挂起线程，而是同步逻辑耗时过长，导致调用栈长期不空，后续任务（包括微任务、宏任务、UI 渲染）无法及时介入。它不来自异步机制失效，而源于本该拆分或移交的同步操作被集中执行。
阻塞的真实发生位置：调用堆栈卡住
JavaScript 本身永不阻塞——但你的代码会。只要同步代码执行时间超过几毫秒（尤其 >16ms），用户就会感知卡顿。关键点在于：
- 调用堆栈未清空前，事件循环不会检查微任务队列，更不会取下一个宏任务
- 浏览器渲染帧（60fps）依赖每 16ms 左右执行一次渲染，若同步任务占满这段时间，页面就“冻结”
- 常见的“假阻塞”场景：大数组遍历、深度递归、复杂正则匹配、未分片的 DOM 批量操作
哪些同步操作容易造成非预期阻塞
这些代码看起来“只是计算”，却极易拖慢整个事件循环：
- 长循环 + 同步 DOM 更新：比如 for 循环中反复 document.createElement、appendChild
- 未节流的事件处理器：resize、scroll、input 触发高频回调，且每次做重排重绘
- 同步 JSON.parse 大字符串：解析 MB 级 JSON 可能消耗数十毫秒
- 未用 Web Worker 的密集计算：如图像处理、加密解密、复杂算法，全部挤在主线程
如何识别和缓解这类阻塞
判断是否是同步逻辑导致的卡顿，比调试异步顺序更关键：
- 打开 Chrome DevTools → Performance 面板 → 录制交互，查看 Flame Chart 中是否有长条状的 Main 线程任务
- 用
console.time()包裹可疑代码段，确认执行耗时是否持续 >5ms - 将长任务主动切片：
requestIdleCallback或setTimeout(fn, 0)分批执行 - 把纯计算移出主线程：用
Web Worker处理数据转换、排序、搜索等
本质上，事件循环从不“阻塞”，它始终在等待。真正卡住它的，是你还没交出控制权的那几行同步代码。
