VSCode调试nodemon报spawn ENOENT，主因是runtimeExecutable未正确定位nodemon：全局安装不可靠，应优先用npm run debug配合request: "attach"、port: 9229、restart: true及--inspect-brk参数，确保VSCode只连接、nodemon负责重启。
VSCode 调试时 nodemon 报 spawn nodemon ENOENT
这是最常卡住的第一步：VSCode 找不到 nodemon。根本原因不是没装，而是 runtimeExecutable: "nodemon" 默认走系统 PATH，完全不认项目里 node_modules/.bin/nodemon 的本地版本。
- Windows 下
node_modules/.bin/nodemon实际是nodemon.cmd，直接写路径会失败 - macOS/Linux 用
npm代理更稳：设runtimeExecutable: "npm"，再用runtimeArgs: ["run", "debug"] - 前提是
package.json里必须有对应 script，例如："debug": "nodemon --inspect-brk ./index.js" - 别信“全局安装就万事大吉”——CI/多项目环境里全局命令不可靠，本地 script 才可控
launch 还是 attach？选错模式调试就断连
request: "launch" 模式下 VSCode 尝试自己拉起 nodemon，但进程生命周期难管理；request: "attach" 是唯一能稳定热重载的路径——VSCode 不启动、只连接，nodemon 负责重启，调试器靠 restart: true 自动重连新进程。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 必须先在终端运行
npm run debug，等看到Debugger listening on ws://127.0.0.1:9229/再点 VSCode 调试按钮 -
launch.json配置重点只有三个："request": "attach"、"port": 9229、"restart": true - 别填
processId：手动选进程不仅慢，还容易选错旧残留进程；固定端口 + restart 才真自动 -
"protocol": "inspector"必须显式写上，否则老版本 Node 可能 fallback 到 legacy 协议导致断连
--inspect-brk 不是可选项，是调试生效的前提
用 --inspect 启动，代码从第一行飞速执行到 app.listen()，你设的断点根本来不及生效；--inspect-brk 强制暂停在入口文件首行，给你留出打断点、看变量、检查依赖初始化的时间。
- 哪怕你只在路由函数里设断点，也得加
-brk——Express 的app.use()、数据库连接、中间件注册都在 require 后立刻执行 - VSCode 附加后自动 resume，你随时可以删掉旧断点、加新断点，行为和普通调试无异
- 端口没变、
restart: true生效的前提，就是 nodemon 启动时带了--inspect-brk；漏掉这个参数，VSCode 会连都连不上
修改代码后没触发重启？检查 nodemon 监听路径
默认 nodemon 只监听 .js、.mjs、.cjs 和 .json，如果你项目里改的是 .ts、.env 或 .yml，它压根不响应。
- 在
package.jsonscript 里加--ext "js,ts,json,yml"显式声明扩展名 - 用
--watch ./src --watch ./config指定目录，比盲目监听整个项目更准、更少误触 - TS 项目注意：如果用
tsc --watch编译 + nodemon 监听输出目录（如./dist），要确保nodemon启动的是编译后的.js，而不是源码.ts - 改完配置别忘了删掉
node_modules/.cache或 nodemon 的临时状态文件，有时缓存会导致监听失效
--inspect-brk 管停得住，三者缺一不可。漏掉任意一环，你看到的就只是终端里一闪而过的日志，和 VSCode 调试面板里永远灰掉的暂停按钮。 
