VSCode调试NestJS失败主因是调试器未连上真实执行上下文，应采用attach模式监听编译后dist/main.js、端口一致且sourceMap路径对齐的配置方案。
VSCode 调试 NestJS 项目失败，绝大多数情况不是代码写错了，而是调试器根本没连上真正的执行上下文——它要么在跑 src/main.ts（ts-node 动态编译），要么在找不存在的 source map 路径，要么端口压根没暴露。稳定可用的配置只有一条路径：用编译后代码 + 正确映射 + attach 模式。
launch.json 必须用 attach，不能用 launch
很多人照着教程写 request: "launch"，结果断点全灰。因为 launch 模式下 VSCode 会自己拉起进程，但 NestJS 的 start:debug 脚本已经带了 --inspect，重复启动会导致端口冲突或 inspector 未就绪。正确做法是让 VSCode 只监听，不启动：
-
request设为"attach" -
port必须和npm run start:debug中指定的端口一致（默认9229） - 删掉
runtimeExecutable和runtimeArgs，它们属于launch场景 - 加上
"restart": true，这样服务重启后调试器自动重连
典型配置片段：
{
"type": "node",
"request": "attach",
"name": "Attach to NestJS",
"port": 9229,
"restart": true,
"protocol": "inspector",
"skipFiles": ["<node_internals>/**"]
}
package.json 的 start:debug 脚本必须暴露 --inspect
检查你的 package.json 里有没有这一行：
"start:debug": "nest start --debug 9229"
如果用的是自定义脚本，比如 node --inspect=0.0.0.0:9229 dist/main.js，注意两点：
- 必须用
dist/main.js，不能是src/main.ts -
--inspect=0.0.0.0:9229中的=0.0.0.0不能省，否则 Windows/macOS 上可能绑定失败
运行前确认终端输出里有类似 Debugger listening on ws://127.0.0.1:9229/...，没有就说明脚本没生效。
tsconfig.json 和 launch.json 的 sourceMap 路径必须对齐
断点不命中，80% 是因为 source map 找不到原始 .ts 文件。三个地方要同步检查：
-
tsconfig.json中"sourceMap": true和"outDir": "dist"必须同时存在且未被extends覆盖 -
launch.json中outFiles应设为["${workspaceFolder}/dist/**/*.js"]（注意**，漏掉就找不到users/users.controller.js这类嵌套路径） - 确保 VSCode 当前打开的是项目根目录，不是子文件夹——否则
.vscode/launch.json不加载
验证方式：启动调试后，打开 Chrome 访问 chrome://inspect，看 Remote Target 列表里有没有你的 NestJS 进程。
生成模块后断点仍不触发？注册和编译缺一不可
nest g co users 生成的控制器，光有文件不行。两个硬性条件缺一不可：
- 该控制器必须出现在对应模块的
@Module({ controllers: [UsersController] })数组中（CLI 通常已写入，但需确认） - 该模块必须被导入到
AppModule的imports: []里（CLI 不自动做这步，必须手动加import { UsersModule } from './users/users.module';）
另外，别在 main.ts 打断点——Nest 启动太快，你几乎抓不到；真正该打的地方是控制器方法体内部，比如 @Get() findAll() 函数的第一行。
最常被忽略的一点：改完代码后，如果用的是 npm run start:dev，它不会触发 debugger 重连；只有 start:debug 配合 attach 模式才能保证每次重启后断点依然有效。
