最稳定的方式是用 nodemon 启动并开启 --inspect-brk，再让 vscode 以 attach 模式连接端口 9229；launch 模式因进程接管冲突易失败，且需确保 nodemon 先运行、vscode 后附加。
直接用 nodemon 配合 VSCode 的 attach 模式，是最稳定、最不容易翻车的方式。别折腾 launch 模式下让 VSCode 自己拉起 nodemon，Windows 上大概率报 spawn nodemon ENOENT，macOS/Linux 也可能因路径解析失败静默退出。
为什么不能用 request: "launch" 直接跑 nodemon
VSCode 的 launch 模式会尝试接管进程生命周期，但 nodemon 本身是个 wrapper，它 fork 新进程、杀旧进程，VSCode 很难准确跟踪和重连。常见后果包括：
-
runtimeExecutable: "nodemon"在 Windows 下找不到nodemon.cmd，报错ENOENT - 写死
"${workspaceFolder}/node_modules/.bin/nodemon"在 macOS/Linux 可能权限或扩展名不匹配 - 即使启动成功，修改代码后 VSCode 不自动重连，调试会话中断，得手动点“重启”
正确姿势：终端先起 nodemon，VSCode 只负责 attach
把启动权交给 nodemon，VSCode 只做连接器和断点控制器——这才是热重载调试的合理分工。
- 在
package.json里加一个debug脚本："debug": "nodemon --inspect-brk ./index.js"（入口文件按实际改） - 终端运行
npm run debug，等输出出现Debugger listening on ws://127.0.0.1:9229/再操作下一步 - 在
.vscode/launch.json中添加配置，关键字段只有三个："request": "attach"、"port": 9229、"restart": true - 必须显式写
"protocol": "inspector"，否则 Node.js 14+ 可能 fallback 到 legacy 协议导致断连
--inspect-brk 不是可选项，是生效前提
没加 -brk，Node 进程会从第一行飞速执行到 app.listen()，你设的断点根本来不及命中。尤其 Express 初始化中间件、数据库连接这些逻辑都在 require 后立刻执行。
-
--inspect-brk等价于在入口文件首行插了个debugger，强制暂停，给你留出设断点、看global、检查模块加载状态的时间 - VSCode 附加成功后自动
resume，你随时可以删旧断点、加新断点，行为和普通调试无异 - 如果改了非
.js文件（比如.ts、.env），nodemon默认不监听，得加-e "js,json,ts,env"
真正容易被忽略的是：VSCode 的 restart: true 只在 attach 成功后才生效，而 attach 是否成功，取决于 nodemon 是否已启动并打开调试端口——所以务必先跑 npm run debug，看到 Debugger listening... 再点调试按钮。漏掉这一步，VSCode 会卡在“正在连接”，你却以为是配置错了。
