VSCode断点调试无法直接捕获死循环，需通过Ctrl+C响应判断、Debug Console抓取调用栈、检查sourceMaps配置及排查异步隐式循环来定位。
VSCode断点调试本身无法直接“捕获”死循环，因为死循环不抛异常、不触发断点、不进入 debugger 语句——它只是让 CPU 持续执行同一段代码，而调试器根本没机会介入。真正有效的排查，靠的是中断信号 + 执行上下文快照 + 事件循环状态验证。
Ctrl+C 能否中断，是判断死循环的第一道分水岭
在 VSCode 终端或集成终端中运行程序时，按 Ctrl+C：
- 若光标立刻返回、进程退出 → 不是死循环，可能是阻塞 I/O 或同步等待（如
fs.readFileSync） - 若无反应、光标卡住、几秒后才退出或干脆不动 → 极大概率是 CPU 密集型死循环（
while(true)、空for(;;)、未更新的循环变量） - 若在调试模式（F5）下按
Ctrl+C无效，但终端面板里程序明明在跑 → 说明调试器没 attach 到真实运行进程，你看到的“卡住”其实是调试配置错误，不是代码问题
用 Debug Console 强制抓取当前调用栈
当程序看似卡死但 Ctrl+C 有响应（或你已手动暂停），立即打开 VSCode 的 Debug Console 面板，输入以下任一命令：
console.log(new Error().stack)
或（Node.js 环境）：
process._getActiveHandles()
关键看输出是否包含重复、深度嵌套、或长时间停留在某函数内（如 calculate() → calculate() → calculate()）。如果是，就定位到那个函数，检查循环条件和变量更新逻辑。
- 不要依赖“单步进入”去慢慢走完循环——你可能要按几百次
F11 - 如果
console.log在死循环体内，但 Debug Console 里看不到输出 → 说明 stdout 缓冲未刷新，加process.stdout.flush()或用console.error（更倾向立即输出） - 浏览器环境可输
debugger语句强制中断，但注意：它只在 DevTools 开着时生效；Node.js 中需确保node --inspect启动且调试器连上
launch.json 必须启用 sourceMaps 并禁用跳过文件
很多“断点不命中”其实是源码映射失效，导致你以为停在 for 行，实际执行的是打包后的 while 块。确认你的 launch.json 包含：
"sourceMaps": true,<br>"skipFiles": ["<node_internals>/**", "node_modules/**"]
特别注意：
-
skipFiles里不能漏掉"<node_internals>/**"，否则 V8 内部循环（如Array.prototype.forEach底层）可能被误判为用户代码，断点偏移到奇怪位置 - TypeScript 项目必须确保
tsconfig.json中"sourceMap": true且"inlineSourceMap": false，否则断点会错位 - Webpack/Vite 项目若用
devtool: 'eval-source-map'，VSCode 可能无法绑定源码，改用'source-map'并生成 .map 文件
死循环常藏在异步回调、Promise 链或定时器里
看起来“没循环”的代码，也可能因逻辑错误形成隐式死循环：
-
setInterval(() => { if (done) clearInterval(id); }, 100)—— 若done永远不为true，就是无限定时器 -
Promise.resolve().then(() => { /* 忘记 return */ }).then(...)—— 返回undefined导致链中断，但若后续有catch又吞掉错误，行为可能像卡住 - React/Vue 中
useEffect或watch回调里修改了触发它的依赖项，造成无限 re-run
这类问题不会让 CPU 暴涨，但会让 UI 冻结、请求无响应。验证方式：在疑似回调开头加 console.trace('in effect')，看控制台是否刷屏式打印。
最易被忽略的是：死循环不一定在你自己写的代码里——它可能藏在某个第三方库的初始化逻辑中，尤其当你用了 require 循环引用或软链接污染的 node_modules。先用绝对路径运行 /usr/local/bin/node index.js 排除环境干扰，再回 VSCode 定位。
