死循环会直接冻结JavaScript主线程，使事件循环停摆，导致setTimeout、Promise等异步任务永不执行。因其独占CPU，宏任务与微任务队列均无法推进，UI渲染、用户交互全部失灵。
死循环会直接冻结 JavaScript 主线程，让事件循环彻底停摆——此时哪怕写了 setTimeout、Promise 或 queueMicrotask，它们也永远不会执行。这不是异步机制失效，而是根本没机会轮到它们。
死循环如何掐断事件循环的呼吸
浏览器的 JS 引擎是单线程的，所有同步代码、宏任务、微任务都排队在同一个主线程上执行。一旦进入死循环（比如 while(true) { ... } 或逻辑错误导致无法退出的 for），CPU 时间被无限占用，主线程再无空闲。结果就是：
- 宏任务队列（如
setTimeout、fetch回调）完全停滞，计时器到了时间也无法触发 - 微任务队列（如
Promise.then、queueMicrotask）压根得不到清空机会——因为清空微任务只发生在每次宏任务结束后，而死循环让“宏任务结束”这个节点永远不来 -
requestAnimationFrame不会调用，页面渲染停止，UI 冻结 - 用户交互（点击、滚动、输入）全部失灵，控制台可能无响应
你以为的“异步兜底”，其实形同虚设
很多人误以为加了 setTimeout 或 await 就能避开阻塞，但在死循环面前，这些全是无效操作：
-
setTimeout(fn, 0)只是把fn推入宏任务队列，但队列永远等不到主线程空闲来取出它 -
Promise.resolve().then(...)生成的微任务，连进队列的机会都没有（如果死循环写在then外层）；即使进了队列，也会因无法执行上一个宏任务而卡死 -
queueMicrotask(() => { while(true) {...} })更危险：它把死循环直接塞进微任务队列，一执行就锁死整个微任务清空流程，后续所有宏任务都被拦在门外
真实场景中容易被忽略的“隐性死循环”
不是只有 while(true) 才叫死循环。以下情况同样会实质阻塞事件循环：
- 超长同步计算：比如遍历千万级数组且每轮做复杂运算，耗时数百毫秒以上，虽非“无限”，但足以让 UI 卡顿、动画掉帧、用户操作延迟
- 错误的递归终止条件：函数递归调用未收敛，栈不断增长直至内存溢出或长时间占用主线程
- 轮询式忙等待：
while (data === null) {}等待异步结果，而不是用Promise或回调——这等于主动放弃控制权 - 在事件处理器中意外嵌套同步重绘逻辑，又未做节流，触发连续强制同步布局（layout thrashing），形成事实上的高负载循环
怎么快速判断是不是死循环引发的饥饿
出现以下现象时，应立即怀疑主线程被同步逻辑长期霸占：
- DevTools 的 Performance 面板显示主线程持续 100% 占用，且 Call Stack 中存在明显重复/深度嵌套的同步函数调用
- 设置断点后，
console.log完全不输出，甚至 DevTools 自身响应变慢 - 页面完全无响应，但网络请求（如 Chrome Network 面板）仍可看到新请求发出（说明不是整个进程崩溃，而是 JS 线程卡死）
- 添加的
setTimeout(..., 10)和queueMicrotask都未执行，而同一段代码在简化环境（如空 HTML + 控制台）下正常
