唯一稳定热重载调试路径是attach模式+终端先执行npm run debug；因vscode不读node_modules/.bin且跨平台路径差异，应设runtimeexecutable为"npm"、runtimeargs为["run","debug"]，并配--inspect-brk确保断点生效。
直接结论：别用 launch 模式硬拉 nodemon，改用 attach 模式 + 终端先跑 npm run debug，这是唯一稳定能热重载调试的路径。
为什么 runtimeExecutable: "nodemon" 总报 spawn nodemon ENOENT
VSCode 默认不读项目 node_modules/.bin，"nodemon" 这个字符串会去系统 PATH 找，不是你本地装的那个。Windows 下 node_modules/.bin/nodemon 实际是 nodemon.cmd，直接写路径会失败；macOS/Linux 也常因 shell 环境未继承导致找不到。
- 最稳解法：把
runtimeExecutable设为"npm"，再用runtimeArgs: ["run", "debug"] - 前提是你
package.json里必须有对应脚本："debug": "nodemon --inspect-brk ./src/index.js" - 别信“全局安装 nodemon 就万事大吉”——CI、多项目、不同 Node 版本下，全局命令不可控
launch 和 attach 模式到底该选哪个
launch 模式让 VSCode 自己启动进程，但 nodemon 的生命周期（杀旧进程、启新进程）它管不住，断点常失效、调试器连不上旧端口就卡死；attach 模式只负责连接，重启交给 nodemon，restart: true 才真有用。
- 必须先在终端执行
npm run debug，等看到Debugger listening on ws://127.0.0.1:9229/再点 VSCode 调试按钮 -
launch.json关键字段只有三个："request": "attach"、"port": 9229、"restart": true -
"protocol": "inspector"必须显式写上，否则老 Node 版本可能 fallback 到 legacy 协议断连 - 别填
processId——手动选进程容易选到残留旧进程，固定端口 +restart才算自动
--inspect-brk 不是可选项，是断点生效的前提
用 --inspect 启动，Node 进程从第一行飞速执行到 app.listen()，你设的断点根本来不及命中；--inspect-brk 强制停在入口文件首行，给你留出时间设断点、检查 require 顺序、确认数据库连接状态。
- 哪怕你只在路由 handler 里设断点，也得加
-brk—— Express 的app.use()、中间件加载、配置初始化全在 require 后立刻执行 - VSCode 附加后自动 resume，你随时可以删断点、加新断点，行为和普通调试无异
- 漏掉这个参数，
restart: true也白搭——新进程没开调试端口，VSCode 连都连不上
修改代码后 nodemon 没重启？检查监听范围
默认 nodemon 只监听 .js、.mjs、.cjs 和 .json，如果你改的是 .ts、.env、.yml 或 .graphql，它压根不响应。
- 在项目根目录加
nodemon.json，显式扩展监听类型：{"ext": "js,json,ts,yml,env"} - 如果用 TypeScript，别只监听
.ts——还要确保outDir不在 watch 范围内，否则编译输出触发二次重启 - 注意
ignore规则是否误杀了关键路径，比如"node_modules/**"写成"node_modules/*"可能漏掉子包
真正容易被忽略的是：restart: true 只在 attach 成功后才生效，而 attach 是否成功，取决于 nodemon 是否已启动并打开调试端口——所以务必先跑 npm run debug，等终端明确输出调试地址，再点 VSCode 调试按钮。
