事件循环直接决定主线程响应能力，是前端和node.js应用性能总开关；其被拖慢或阻塞会导致页面卡顿、动画掉帧、接口延迟等，根源常为长任务、队列失衡或未利用空闲期。
JavaScript 事件循环直接决定主线程是否“忙得过来”——它不是后台调度器，而是前端和 Node.js 应用响应能力的总开关。系统性能表现（如页面卡顿、接口延迟、动画掉帧）往往不是硬件不够，而是事件循环被拖慢或阻塞。
主线程争抢：JS 执行与 UI 渲染共用一条路
浏览器中，JavaScript 执行、样式计算、布局、绘制全部挤在同一个主线程上。事件循环每轮调度任务时，若同步代码耗时超过 16.6ms（即一帧时间），浏览器就来不及完成渲染，用户就会感知到卡顿或白屏。
- 一个 for 循环执行 1e8 次，可能占用主线程 200ms+，期间所有点击、滚动、动画都会冻结
- 频繁触发的 resize 或 scroll 回调若未节流，会瞬间堆积几十个宏任务，压垮事件循环
- DOM 批量操作未合并，每次修改都触发重排重绘，进一步延长单次任务耗时
任务队列失衡：微任务过长或宏任务过密
微任务虽优先级高，但“清空式执行”特性也带来风险：如果 Promise 链持续生成新微任务（如递归 resolve），微任务队列永远清不完，后续宏任务（包括 UI 渲染、setTimeout）就被无限推迟。
- MutationObserver监听大量 DOM 变化时，回调若处理不当，可能一次触发上百个微任务
- 滥用 queueMicrotask做高频状态更新，等同于主动制造微任务风暴
- 大量 setTimeout(fn, 0) 并发注册，虽不阻塞，但会密集抢占下一轮宏任务时机，干扰渲染节奏
CPU 密集型操作：事件循环被“焊死”
Node.js 或前端复杂计算（如图像处理、加密、大数据解析）若在主线程同步执行，事件循环完全停滞——没有机会取新任务，I/O 回调积压、定时器失准、HTTP 请求无法响应。
- JSON.parse 处理超大字符串、正则回溯爆炸、未分片的数组 reduce 都是典型阻塞源
- Node.js 中使用 fs.readFileSync 替代异步读取，等于主动放弃事件循环优势
- 前端未用 Web Worker 卸载计算，却指望“拆成 setTimeout”解决一切，效果有限
空闲资源浪费：没利用好浏览器的闲置窗口
事件循环并非时刻高负荷。浏览器在两次渲染之间、任务执行间隙存在空闲时段，但默认不会自动调度低优先级工作。
- 非关键逻辑（如日志上报、预加载非首屏数据）未用 requestIdleCallback，只能硬抢宏任务时机
- 动画帧敏感操作未对齐 requestAnimationFrame，导致强制同步布局或丢帧
- 大量微任务塞满空闲期，反而挤占了本可用于渲染的时间片
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
