Node.js断点不命中需先确认launch.json配置正确：应使用"type": "node"、"request": "launch"和"program"指定入口文件，而非Attach模式；未捕获异常中断需启用“Uncaught Exceptions”断点，Promise拒绝需额外勾选“Uncaught Promise Rejections”，已捕获异常中断需开启“Pause on caught exceptions”或配置exceptions。

Node.js 断点不命中？先确认 launch.json 启动方式是否正确

VS Code 内置 Debugger 捕获不到 Node 运行时错误，90% 的原因是没让 Node 以调试模式启动。npm start 默认不启用 --inspect，所以你打的断点永远不会触发。

• ✅ 正确配置："type": "node" + "request": "launch" + "program": "${workspaceFolder}/index.js" —— VS Code 自己拉起带 --inspect-brk 的进程
• ❌ 错误做法：手动运行 npm start，再选 Attach to Process —— 除非你在 package.json 的 script 里显式加了 --inspect，否则连不上调试协议
• ⚠️ 注意："stopOnEntry": false 和异常捕获无关，它只控制是否停在第一行；真正影响异常中断的是 exceptions 配置或调试面板里的异常断点开关

未捕获的错误（Uncaught Exception）怎么立刻中断？

默认情况下，VS Code 不会在 throw 那一刻暂停——它只等你打的普通断点。要让调试器一抛错就停，必须启用「异常断点」，不是靠改代码。

• 打开左侧「运行和调试」面板 → 点击「断点」区域下方的「+」→ 选择「Node.js: Uncaught Exceptions」
• 或者直接在调试面板右上角 ⋯ → 勾选「Uncaught Exceptions」
• 该设置生效后，只要抛出未被 try/catch 捕获的错误（比如 TypeError、ReferenceError），执行会立刻停在 throw 行，而非打印堆栈后退出
• 注意：Promise.reject(new Error()) 属于异步未捕获异常，默认不触发，需额外勾选「Uncaught Promise Rejections」

已捕获的错误（Caught Exception）也能中断，但得手动开

有些 bug 发生在 catch 块内部逻辑里，比如错误处理本身又出错了，或者你想看异常源头在哪抛的。这时需要让调试器停在 catch 语句入口处。

Rydberg Agent Node

使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r

下载

• 调试面板右上角 ⋯ → 勾选「Pause on caught exceptions」（Chrome 调试器支持，Node.js 也兼容）
• 或在 launch.json 中显式配置："exceptions": { "caught": true, "uncaught": true }
• ⚠️ 风险：一旦开启，所有 try/catch 都会中断，包括第三方库里的正常错误处理，容易干扰调试节奏；建议只在定位特定问题时临时启用
• 常见误判：你以为开了「Uncaught Exceptions」就能看到所有异常，但若代码里写了 try { ... } catch (e) { }，错误就被吞了，断点根本不会触发

为什么异常断点打了却没停？检查这三件事

不是配置漏了，就是环境或类型没对上。异常断点失效往往卡在细节上。

• runtimeExecutable 路径不对：如果你用 nvm 切换 Node 版本，VS Code 可能找不到当前 shell 下的 node 或 nodemon。运行 which node，把输出路径填进 launch.json 的 "runtimeExecutable" 字段
• 异常类型不匹配：比如你只勾了 Exception，但实际抛的是 TypeError 子类，在某些调试器实现中不会自动向上匹配父类；Node.js 场景下，直接勾「Uncaught Exceptions」更稳妥
• "justMyCode": true（Python）或 "skipFiles"（Node.js）导致跳过关键帧：确保 "skipFiles" 没把你的源码路径误加入，例如不要写成 "**/node_modules/**" 却漏掉了 "${workspaceFolder}/**"

真正难调试的从来不是语法错误，而是那些“看起来没报错，但结果不对”的情况——这时候异常断点配合条件断点（比如 error.message.includes("timeout")）才是关键。别依赖 console.log 猜，让调试器告诉你错误发生时的真实上下文。