事件循环是JavaScript性能问题的“显微镜”，真正影响体验的是任务在其中的位置和持续时间；宏任务每次执行一个，微任务在宏任务后全部清空，避免微任务风暴；长任务（>50ms）阻塞渲染，需用Performance面板识别；高频事件须节流或委托；内存泄漏会加剧GC压力，应使用WeakMap并及时清理定时器与监听器。
事件循环是 JavaScript 性能问题的“显微镜”——它不直接导致卡顿，但所有卡顿都绕不开它。真正影响体验的，不是某段代码写得不够优雅，而是它在事件循环中的位置和持续时间。主线程一旦被长时间占用，渲染、响应、动画全都会停摆。
看懂任务分类：宏任务 vs 微任务
性能瓶颈常藏在任务类型混淆里。宏任务（setTimeout、setInterval、I/O、UI 渲染）每次只执行一个；微任务（Promise.then、MutationObserver、queueMicrotask）则会在每个宏任务结束后被全部清空。如果微任务里又创建新微任务，就可能形成“微任务风暴”，让主线程无法及时交还给渲染。
- 检查 Promise 链是否过长，尤其避免在 .then 中同步递归调用自身
- 用 Chrome DevTools 的 Performance 面板 录制操作，展开“Main”线程，观察是否有连续密集的紫色（微任务）或橙色（宏任务）长条
- 注意 MutationObserver 的回调触发频率——监听整个 document 变化时，一次 DOM 批量更新可能引发上百次回调
识别长任务：阻塞渲染的元凶
Chrome 定义“长任务”为持续超过 50ms 的同步执行。这类任务会直接打断帧渲染（60fps 要求每帧 ≤16.6ms），造成肉眼可见的卡顿。事件循环本身不会变慢，但长任务会让它“来不及喘气”。
- 打开 DevTools → Performance → 点击录制 → 操作页面 → 停止后查看“Main”轨道中 >50ms 的红色块
- 常见来源：大数组遍历、JSON.parse 大文本、未拆分的 Canvas 绘图、同步正则匹配超长字符串
- 验证方式：把疑似长函数包裹进 console.time() / console.timeEnd() 快速定位耗时点
排查事件监听器失控
滚动、缩放、鼠标移动等高频事件，若未节流或委托，会在事件循环中堆积大量待执行的宏任务。它们未必单个很重，但高频+无控制造成“任务雪崩”。
立即学习“Java免费学习笔记（深入）”；
- 用 Elements 面板 → 右键元素 → “Break on” → “attribute modifications” 辅助判断是否因样式/属性变更反复触发监听
- 检查是否遗漏 removeEventListener，尤其 SPA 页面切换时——残留监听器会持续接收事件并入队
- 优先用事件委托代替遍历绑定；对 scroll/resize 使用 throttle（固定间隔执行）而非 debounce（最后一次才执行），避免用户操作完全无反馈
警惕内存压力干扰循环节奏
频繁垃圾回收（GC）本身是微任务，但它会暂停主线程。当内存占用持续走高，V8 会更激进地触发 GC，进一步挤压可用执行时间——这时事件循环没变慢，但有效工作时间被压缩了。
- 在 DevTools 的 Memory 面板 中录制堆快照，对比页面操作前后的对象数量，重点关注 detached DOM 节点、闭包中意外保留的大数组
- 检查定时器是否被遗忘：setInterval 在组件卸载后仍运行，会不断向作用域注入新引用
- 避免将 DOM 元素直接作为对象 key（如 map.set(element, data)），改用 WeakMap 防止强引用阻碍回收
