attach模式调试nestjs最可靠，因它直接附加到由nest start --watch --debug启动的node进程，避免断点错位、环境变量丢失、手动重启及argv参数缺失等问题。
直接运行 main.js 或选中 src/main.ts 启动调试，大概率断点失效、环境变量丢失、改代码后不自动重启——这不是你配置错了，是 NestJS 的启动机制和 WebStorm 的 launch 模式天然冲突。
为什么不能用 “Run” 直接启动 NestJS 入口文件
NestJS 默认靠 @nestjs/cli（即 nest start）驱动，它封装了 TypeScript 编译、watch 重载、环境变量注入、命令行参数解析（如 --config）、模块注册等逻辑。WebStorm 若直接执行 main.js 或 ts-node src/main.ts：
- 跳过
nest start的生命周期管理，process.argv为空，所有 CLI 参数（如--watch）失效 -
ts-node编译路径与 WebStorm 调试器 source map 映射错位，断点打在 TS 行却停在 JS 文件任意位置 - 修改代码后不会触发
--watch重启，必须手动停止再点 Debug 图标 -
NODE_ENV、APP_ENV等环境变量未按.env或 CLI 规则加载，常导致 ConfigModule 初始化失败
正确做法：用 Attach to Node.js/Chrome 配置
本质是让 WebStorm 作为“监听者”，连接已由 CLI 启动的、带调试端口的 Node 进程——所有编译、重启、环境加载都由 nest 命令完成，IDE 只负责断点和变量观察。
- 终端执行：
nest start --watch --debug=9229（端口可换，但需与下一步一致） - WebStorm → Run → Edit Configurations → + → Attach to Node.js/Chrome
- Host:
localhost，Port:9229（必须与上一步命令中--debug值一致） - 勾选
Auto-open in browser是可选的，不影响调试本身 - 点击 Debug 图标（甲虫）即可连接；此时修改任何
.ts文件，--watch自动重编译并重启进程，断点仍有效
npm script 方式也能用，但有隐藏陷阱
若 package.json 中定义了 "start:debug": "nest start --debug --watch"，可用 npm 类型配置，但必须避开一个关键坑：
- 配置类型选
npm，Script 填start:debug，CWD 设为项目根目录 -
务必取消勾选 “Node interpreter” 区域下方的
Run with JavaScript debugger - 勾选它 = WebStorm 尝试自己 launch 进程，又回到第一种失败模式；不勾选 = 它只执行 npm 命令，然后自动 attach 到暴露的调试端口
- 该方式稳定性略低于纯 Attach 模式，因 npm 启动过程多一层 wrapper，偶尔会延迟 attach
source map 不生效？三个地方必须同时满足
断点打在 app.controller.ts 却停在 dist/app.controller.js 里，说明 source map 没被识别或没生成：
-
tsconfig.json或tsconfig.build.json中必须含"sourceMap": true - WebStorm 设置 → Languages & Frameworks → TypeScript → 勾选
Enable TypeScript compiler（否则 IDE 不参与编译，不生成 .map） - 构建产物目录（如
dist/）下要真实存在.js.map文件；若用nest build，检查输出目录是否包含它们 - 首次 attach 失败时，先
ls -l dist/**/*.map确认文件存在，再检查 WebStorm 的 Debugger → JavaScript → Source Maps 是否启用
真正麻烦的从来不是配端口或点按钮，而是搞清 NestJS 的 CLI 启动链路和 WebStorm 的 attach 时机如何对齐——只要进程是 nest start --debug 拉起来的，IDE 就只是个“远程探针”，其余交给框架本身。其他所有绕开 CLI 的方式，迟早会在某次热重载后让你重新找断点。
