死循环不会自动报错但会导致浏览器卡死、cpu飙升、页面无响应；需用chrome devtools performance面板抓长任务定位超长js执行块，结合console和memory面板验证内存增长与对象暴增，再通过断点或debugger中断并检查循环变量，最后以计数器+break实现防御性兜底。
死循环不会自动报错，但会让浏览器卡死、CPU飙升、页面无响应。排查和终止的关键不是等它崩溃，而是用工具主动识别异常行为并干预。
用 Chrome DevTools Performance 面板抓长任务
死循环本质是主线程被一个函数持续占用，表现为超长的 JavaScript 执行块（>50ms）。打开 DevTools → Performance → 点击 Record → 触发疑似问题操作（比如点击某个按钮后页面卡住）→ 停止录制：
- 在火焰图（Flame Chart）中找红色或深橙色的“长条”，尤其关注连续堆叠、无中断的 JS 调用栈
- 展开该长条，看顶层函数名和源码位置——大概率就是死循环所在的 while 或 for 语句
- 右侧 Summary 面板会显示 Total time 和 Self time，若某函数占时远高于其他，且调用次数异常高（如几万次），基本可确认
配合 Memory 和 Console 快速验证
Performance 只能定位“谁在狂跑”，还需交叉验证是否真为死循环：
- 切换到 Console 面板，输入 performance.memory 查看内存增长趋势；若 JS 堆持续上涨且不回落，说明循环体里可能有变量累积或闭包引用
- 在疑似循环代码前加 console.time('loop')，循环体内加 console.timeLog('loop')；如果日志飞速刷屏、时间戳几乎不变，就是典型死循环信号
- 打开 Memory 面板 → Take Heap Snapshot，对比卡顿前后快照，若某对象数量暴增（如数组、监听器），说明循环未正确退出且持续创建新实例
强制中断运行中的死循环
一旦确认是死循环，不能靠刷新页面硬扛——尤其在调试别人代码或沙箱环境时：
- 在 Sources 面板中找到对应脚本，直接在循环体第一行打断点，然后按 F8 继续执行；若断点反复命中且变量值不更新，立刻暂停并检查循环变量修改逻辑
- 在控制台手动执行 debugger 触发断点，再用 Call Stack 查看当前执行深度；若栈深度超过 1000 层，基本是递归失控或 while 没更新条件
- 对无法修改源码的场景（如用户提交的脚本），可用 Web Worker 隔离执行，并设 timeout：Worker 内用 self.postMessage 定期上报进度，主进程监听超时后调用 worker.terminate()
上线前加防御性兜底机制
靠工具排查是事后补救，真正防住得靠编码习惯：
- 所有 while(true) 或复杂条件循环，必须配计数器 + break：例如 let steps = 0; const MAX = 1e4; while (condition && steps++
- 避免浮点运算做循环判断，如 while (x !== 0.1)；改用整数步进或误差容忍（Math.abs(x - 0.1) ）
- 在开发环境注入全局检测钩子：定义 window.__loopGuard = { count: 0 }，循环体末尾加 if (++__loopGuard.count > 1e5) throw 'Loop limit exceeded'
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
