VSCode调试NestJS断点灰掉，主因是launch模式与--inspect冲突导致连接失败；应改用attach模式，配置port匹配、outFiles含**、sourceMap启用，并确保start:debug运行dist/main.js。
VSCode 调试 NestJS 项目失败，90% 是因为没走编译后路径 + 源映射断链，而不是代码写错了。
为什么 launch.json 用 request: "launch" 总是断点灰掉
VSCode 的 request: "launch" 会自己拉起新进程，但 NestJS 的 start:debug 脚本（比如 nest start --debug 9229）已经带了 --inspect。两者一叠加，要么端口被占，要么 inspector 还没就绪调试器就去连了——结果就是断点变灰色、提示 “unbound breakpoint”。
真正稳定的做法是让 VSCode 只监听，不启动：
-
request改成"attach" - 删掉
runtimeExecutable和runtimeArgs - 确保
port和脚本里--inspect的端口完全一致（默认9229） - 加上
"restart": true，服务重启后自动重连
package.json 里的 start:debug 脚本必须暴露 --inspect 且绑定到 dist/main.js
很多项目误用 ts-node src/main.ts --inspect 启动，这会导致 VSCode 看到的是 TypeScript 源码，而实际执行的是 ts-node 动态编译的中间态，source map 映射错位，断点偏移或失效。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
正确路径只有一条：先编译，再运行 dist/main.js。
- 脚本推荐写法：
"start:debug": "node --inspect=0.0.0.0:9229 dist/main.js" - 必须带
=0.0.0.0:9229，不能只写:9229，否则 Windows/macOS 上可能绑定失败 - 启动后终端必须出现
Debugger listening on ws://127.0.0.1:9229/，没有就说明脚本没生效 - 如果用
nest start --debug 9229，确认它底层确实生成并运行了dist/main.js（可通过nest build后手动验证）
tsconfig.json 和 launch.json 的 sourceMap 路径必须对齐
断点不命中，80% 是因为 VSCode 找不到原始 .ts 文件。三个地方必须同步检查：
-
tsconfig.json中"sourceMap": true和"outDir": "dist"必须同时存在，且没被"extends"覆盖（可运行npx tsc --showConfig验证最终配置） -
launch.json中outFiles必须设为["${workspaceFolder}/dist/**/*.js"]—— 注意**，漏掉就找不到users/users.controller.js这类嵌套路径下的文件 - VSCode 必须打开项目根目录（不是子文件夹），否则
.vscode/launch.json不加载
Controller 和 Service 断点没反应？先确认它真被 Nest 加载了
main.ts 里打的断点基本没用——Nest 初始化太快，等调试器 attach 上时，模块树早就建完了。真正要调试业务逻辑，断点得落在框架实际执行的位置：
- 控制器方法内部（
@Get()/@Post()装饰器下的函数体） - 守卫（
CanActivate）、拦截器（NestInterceptor）、过滤器（ExceptionFilter）的canActivate、intercept、catch方法 - 服务方法里，但前提是该服务已被注入到某个 controller 或 module 的
providers里 - 如果断点始终不触发，检查对应 Controller 是否被
imports或controllers注册；没注册 = 没加载 = 不执行
复杂点在于：依赖注入链越深，断点位置越容易被忽略——比如一个 @Injectable() 类被多个模块复用，但只在某一个模块的 providers 里声明了 useClass，那只有那个模块下的调用才进得去。
