VSCode调试NestJS失败主因是调试器未连上真实执行上下文，必须用attach模式、编译后代码、正确sourceMap映射及端口绑定。需设request为"attach"、port与start:debug一致（默认9229）、执行dist/main.js并暴露--inspect=0.0.0.0:9229、tsconfig.json启用sourceMap和outDir、launch.json配置outFiles为"${workspaceFolder}/dist/*/.js"，禁用start:dev。
VSCode 调试 NestJS 失败，绝大多数不是代码问题，而是调试器根本没连上真实执行上下文——它要么在跑 src/main.ts（ts-node 动态编译），要么找不到 sourceMap，要么端口没暴露或绑错。稳定可用的路径只有一条：用编译后代码 + 正确映射 + attach 模式。
必须用 attach 模式，不能用 launch
launch.json 里 request 必须设为 "attach"，不能是 "launch"。因为 npm run start:debug 已经带了 --inspect 启动 inspector，launch 模式会让 VSCode 自己再拉一个进程，导致端口冲突或 inspector 未就绪，断点全灰。
-
type设为"node" -
port必须和package.json中start:debug指定的端口一致（默认9229） - 删掉
runtimeExecutable和runtimeArgs—— 它们只属于launch场景 - 加上
"restart": true，服务重启后调试器自动重连
start:debug 脚本必须运行 dist/main.js 并暴露 --inspect
检查你的 package.json 是否有类似这一行：
"start:debug": "nest build && node --inspect=0.0.0.0:9229 dist/main.js"
关键点：
- 必须显式执行
dist/main.js，不能是src/main.ts或任何ts-node命令 -
--inspect=0.0.0.0:9229中的=0.0.0.0不能省，否则 Windows/macOS 上可能绑定失败 - 运行前确认终端输出里有
Debugger listening on ws://127.0.0.1:9229/...，没有就说明脚本没生效
sourceMap 必须对齐：tsconfig.json 和 launch.json 都要配
断点不命中，80% 是因为 source map 找不到原始 .ts 文件。
-
tsconfig.json中必须有："sourceMap": true和"outDir": "dist" -
launch.json中outFiles必须写成：["${workspaceFolder}/dist/**/*.js"]（漏掉**就找不到嵌套路径下的文件） - 如果启用了
"incremental": true但没清缓存，旧的.js.map可能残留；验证方法是打开任意dist/**/*.js，末尾找//# sourceMappingURL=xxx.js.map，确认该文件真实存在且内容可读
别用 npm run start:dev 调试
npm run start:dev 底层依赖 nodemon 或 ts-node-dev，它们会反复 kill & restart 进程。--inspect 端口在进程退出时立即释放，VSCode 调试器连不上新进程，表现为“改完代码服务重启了，但所有断点全灰”。
- 调试阶段请彻底停用
start:dev - 改用
npm run start:debug（确保它执行的是编译后代码） - 如果项目用了
pnpm或yarn，tasks.json中的command要手动写成"pnpm run build"，别依赖 VSCode 自动生成的tsc任务
最稳的验证方式：在 Controller 方法内设断点，那里请求上下文完整，@Inject 结果才真实可靠。别在 onModuleInit 或构造函数太早的位置打点，容易因异步初始化未完成而看到 undefined。
