死循环会彻底阻塞事件循环，导致页面无响应、DevTools无法交互、调试器失效——必须用“外部介入+快速冻结”策略定位：先按快捷键强制暂停执行以查看Call Stack，再结合Performance面板识别长任务源头，最后在Sources面板中排查while/for等无退出条件的高风险代码。
死循环会彻底阻塞事件循环，导致页面无响应、DevTools无法交互、调试器失效——这种情况下不能靠常规断点或Performance面板录制，必须用“外部介入+快速冻结”策略定位。
立即暂停执行，避免页面完全卡死
一旦发现页面假死（按钮无响应、console不输出、滚动卡住），不要反复刷新或关闭标签页。直接按 Ctrl+Shift+I（Windows/Linux）或 Cmd+Option+I（macOS） 打开 DevTools，然后立刻按 F8 或 Ctrl+\ 触发“Resume script execution”切换为“Pause script execution”。这个操作会强制 JS 引擎中断当前正在运行的同步代码，哪怕它卡在 while(true){} 或深度递归里。
暂停后，Call Stack 面板会显示当前卡在哪一行、哪个函数中，这是最直接的定位依据。
用 Performance 面板反向识别长任务源头
如果还能在卡死前短暂操作 DevTools，可快速启用 Performance 面板：
立即学习“Java免费学习笔记（深入）”；
- 打开 Performance → 点击录制（●）→ 等待几秒 → 立即停止（■）
- 查看 Main 轨道：找到持续占用主线程、宽度远超 100ms 甚至数秒的“巨型脚本块”
- 点击该色块 → 在 Summary 中看 “Activity” 和 “Call Stack”，重点关注自定义函数名（非浏览器内置方法）
- 若看到重复出现的同一函数调用栈（如
renderLoop→updateState→ 自身），基本可确认是递归/循环未退出
检查 Sources 面板中的可疑代码模式
暂停后，Sources 面板通常仍可展开文件树和源码。重点扫描以下高风险写法：
while (condition) { /* 没有修改 condition 的语句 */ }for (let i = 0; i （数组边遍历边增长）- 递归函数缺少终止条件，或终止条件永远不满足（如
if (n === 0) return; factorial(n - 1);但传入负数） - 监听器内反复触发自身（如
input.addEventListener('input', handler); handler() { input.value = 'x'; }）
这些代码在暂停状态下会高亮显示在 Call Stack 对应的源码行，可直接编辑修复后右键选择 “Save and continue”（需已启用 Workspaces 或本地文件映射）。
预防性措施：加主动检测与超时保护
纯靠 DevTools 定位是被动手段。建议在开发阶段就嵌入防护逻辑：
- 对可能长时间运行的循环加计数器和跳出判断：
let steps = 0; while (condition && steps++ - 用
setTimeout或queueMicrotask拆分大任务，避免单次执行过久 - 在关键入口处打日志：
console.time('heavyLoop');+console.timeEnd('heavyLoop');，便于后续回溯 - 启用 Chrome 的“Long Task”警告：在 DevTools → Settings → Experiments 中开启 “Highlight long tasks in timeline”
死循环不是异步调度问题，而是同步执行失控。DevTools 的价值不在“观察队列”，而在“强行中断+回溯现场”。只要能暂停，就能看到它卡在哪。
