vscode通过attach模式配合nodemon实现热重载调试：先运行npm run debug（含--inspect-brk），再在launch.json中配置"request": "attach"、"port": 9229和"restart": true，确保调试器自动重连新进程。
VSCode 本身不直接重启调试会话，但可以和 nodemon 配合，在代码保存后自动重启 Node 进程，并让调试器重新附加——关键不是“VSCode 重启”，而是“VSCode 主动连接新进程”。
用 attach 模式连接 nodemon 启动的进程
这是最稳定、兼容性最好的方式。VSCode 不控制启动，只负责监听和附加，避免了 runtimeExecutable 在不同系统路径下失效的问题。
-
nodemon必须带--inspect（或--inspect-brk）参数启动，否则没有调试端口 - 在
package.json中配一个debug脚本："debug": "nodemon --inspect-brk ./index.js"（路径按实际入口改） - 终端里先运行
npm run debug，等看到Debugger listening on ws://127.0.0.1:9229/... - 在
.vscode/launch.json中添加一个attach配置，重点字段："request": "attach"、"protocol": "inspector"、"restart": true -
"processId": "${command:PickProcess}"是可选的；更推荐固定端口 +"port": 9229，省去手动选进程
launch 模式下用 runtimeExecutable 的坑
很多人试图让 VSCode 直接执行 nodemon，结果在 Windows 上报 spawn nodemon ENOENT，或 macOS/Linux 找不到本地 node_modules/.bin/nodemon。
-
runtimeExecutable值不能写死为"nodemon"：它默认走系统 PATH，不读项目node_modules - 写成
"${workspaceFolder}/node_modules/.bin/nodemon"看似合理，但在 Windows 下可能因扩展名（.cmd）失败 - 更稳妥的写法是用
"npm"作为runtimeExecutable，再通过runtimeArgs调用脚本："runtimeArgs": ["run", "debug"] - 此时必须确保
package.json里有对应 script，且该 script 显式包含--inspect
为什么 --inspect-brk 比 --inspect 更适合调试
加了 -brk 会让进程在第一行就暂停，确保你在断点设好前，代码不会跑过初始化逻辑（比如 Express 的 app.use、数据库连接等）。
- 没加
-brk时，如果断点设在 require 之后、app.listen()之前，很可能根本停不住 -
--inspect-brk本质是加了debugger断点，VSCode 附加后自动继续，你仍可随时在任意行设新断点 - 注意：如果用了
attach模式且指定了port，--inspect-brk和--inspect对 VSCode 行为没区别，但对人眼确认“进程已就绪”很关键
真正容易被忽略的是：VSCode 的 restart: true 只在 attach 成功后才生效，而 attach 是否成功，取决于 nodemon 是否已启动并打开调试端口——所以务必先跑 npm run debug，再点 VSCode 的绿色三角形。顺序反了，调试器会卡在“等待连接”。
