attach模式调试nestjs更可靠，因它直接附加到运行中的node进程，避免了ts-node编译与--watch机制绕过导致的断点错位、手动重启、环境变量丢失及argv参数缺失等问题。
直接用 Attach 模式调试 NestJS，比直接运行主文件更可靠——尤其在启用 --watch 时，断点不会错位，改完代码自动重启后仍能命中。
为什么不能直接选 main.js 启动调试？
NestJS 默认使用 ts-node 或 nest start 启动，入口不是纯 JS 文件；若强行指定 main.js（或 src/main.ts），WebStorm 会绕过 TypeScript 编译流程和 --watch 机制，导致：
- 断点位置与源码不一致（TS 行号 vs 编译后 JS 行号）
- 修改代码后需手动重启调试会话
- 环境变量（如
NODE_ENV）未按预期加载 -
process.argv参数丢失，@nestjs/cli的命令行能力失效
正确做法：用 Attach to Node.js/Chrome 配置
先在终端手动启动 NestJS 并暴露调试端口，再让 WebStorm 附加过去。这是目前最稳定、兼容性最好的方式：
- 终端执行：
nest start --watch --debug=9229（端口可换，但需与配置一致） - WebStorm 中：Run → Edit Configurations → + → Attach to Node.js/Chrome
- 填入 Host：
localhost，Port：9229 - 勾选「Auto-open in browser」可选，但非必需
- 点击 Debug 图标（甲虫）即可连接已运行的进程
此时修改 TS 文件，--watch 自动重编译并重启服务，WebStorm 的断点依然有效——因为它是 attach 到运行中的 Node 进程，而非重新 launch。
start:debug 脚本配合 npm 配置也行，但有隐含限制
如果你的 package.json 里定义了："start:debug": "nest start --debug --watch"，也可用 npm 类型配置：
- Run → Edit Configurations → + → npm
- Script：
start:debug - CWD：
${workspaceFolder}（确保是项目根目录） - 关键：取消勾选「Node interpreter」下方的「Run with JavaScript debugger」——否则会尝试 launch 而非 attach，反而失败
- 该方式本质仍是启动新进程，断点稳定性略低于纯 Attach 模式
容易被忽略的关键点
Source map 必须启用，否则断点打在 TS 文件上却停在编译后的 JS 里：
- 确认
tsconfig.build.json或tsconfig.json中有"sourceMap": true - 若用
nest build构建，确保构建产物目录（如dist/）里存在.js.map文件 - WebStorm 的 TypeScript 设置中，Settings → Languages & Frameworks → TypeScript → Enable TypeScript compiler 必须开启（否则不生成 map）
- 首次 attach 失败时，检查终端输出是否含
Debugger listening on ws://127.0.0.1:9229/...——没有说明--debug未生效
