JavaScript事件循环中无尽微任务会完全阻塞DOM渲染更新，因微任务队列必须清空后才进入渲染阶段；此时滚动、点击、动画、rAF均失效，需用setTimeout或节流中断来让出主线程。
JavaScript 的事件循环在遇到无尽微任务循环（如连续 Promise.then 或 queueMicrotask）时，会**完全阻塞 DOM 渲染更新**，包括视口滚动、样式重排、动画帧、输入响应等。这是因为浏览器必须等当前宏任务（如脚本执行、setTimeout 回调）及其所有衍生的微任务全部清空后，才会进入“渲染阶段”。
微任务队列优先级高于渲染
事件循环中，每个宏任务结束后，引擎会**同步、不间断地执行完全部待处理微任务**，期间不穿插任何渲染操作。这意味着：
- 即使你修改了
element.style.height或触发了scrollTo()，只要还在微任务链中，这些变更不会被绘制到屏幕上； - 用户滚动、点击、键盘输入等事件会被排队，但回调要等到微任务彻底结束才能进入事件队列并执行；
- requestAnimationFrame 回调也不会触发——它属于下一个宏任务开始前的“渲染前钩子”，而微任务不释放控制权，就无法进入下一宏任务。
常见无尽微任务陷阱示例
以下代码会让页面完全卡死，视口无法滚动、按钮无法点击、动画冻结：
function endlessMicrotask() {
queueMicrotask(() => {
// 每次微任务又调度一个，永不退出
endlessMicrotask();
});
}
endlessMicrotask(); // ⚠️ 立即阻塞渲染和交互
类似问题也出现在误用 Promise.resolve().then(...) 递归、或某些状态库的同步副作用循环中。
立即学习“Java免费学习笔记（深入）”；
如何打破循环、让渲染恢复
核心原则：**主动让出主线程控制权，强制进入下一轮宏任务**，从而给浏览器留出渲染机会。常用方法：
-
改用
setTimeout(fn, 0)：它把任务推入宏任务队列，当前微任务链结束后立即开始新宏任务，中间插入渲染时机； -
用
requestIdleCallback处理非紧急逻辑，在浏览器空闲时执行，天然兼容渲染节奏； -
加节流判断 + 中断条件：例如限制最大迭代次数，或检查
document.hidden/ 时间戳，避免无限递归； - 将批量 DOM 更新合并后一次性提交，而非在微任务中逐次修改再等待渲染——因为微任务里根本不会渲染。
验证是否卡住渲染的小技巧
开发中可快速检测：
- 尝试滚动页面或按空格键：若无反应，大概率被微任务霸占；
- 打开开发者工具 → Rendering 面板 → 勾选 “FPS Meter” 和 “Paint Flashing”：若数字停滞、屏幕无闪烁，说明渲染被阻塞；
- 在疑似代码段前后加
console.time和performance.now()，观察是否长时间无日志输出且页面冻结。
