vscode调试node.js断点失效主因是launch.json配置与实际运行路径不一致、未启用--inspect-brk或sourcemap未正确映射；需确保program指向可执行js入口、type为"node"、request为"launch"，并验证源码与编译文件路径匹配。
VSCode 调试 Node.js 应用，90% 的断点失效问题不是代码写错了，而是启动参数没对上、launch.json 配置和实际运行路径不一致，或者你根本没让 Node 进程进入调试模式。
为什么 npm start 启动后断点完全不触发
因为 npm start 默认只是执行脚本（比如 node index.js），没加 --inspect-brk 参数，Node 进程压根不暴露调试端口，VSCode 就连不上。
- ✅ 正确做法：在
launch.json中用"request": "launch"+"program"直接指向 JS 入口文件，让 VSCode 自己带--inspect-brk启动进程 - ❌ 错误做法：手动终端跑
npm start，再切回 VSCode 选 “Attach to Process” —— 除非你在package.json的 script 里显式写了--inspect-brk，否则必然失败 - ⚠️ 注意：
--inspect-brk会让进程卡在第一行（适合设启动断点），--inspect不暂停（只适合 attach 场景）
launch.json 必须填对的三个字段
删掉所有可选项，只留最核心的三项，就能跑通调试。其他字段（如 env、args）都是锦上添花，但填错反而坏事。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
-
"type": "node"—— 固定值，别写成pwa-node；老项目或 CommonJS 项目用node更稳 -
"request": "launch"—— 表示“我来启动”，不是“我去连别人”。只有明确要附加到已有进程时才用attach -
"program": "${workspaceFolder}/src/server.js"—— 必须是真实可执行的 JS 文件路径，不能是.ts源码（除非配了ts-node），也不能是./index.js这种相对路径（VSCode 会解析失败）
Express/Koa 路由断点不命中，先查请求有没有真正进来
服务控制台显示 Listening on port 3000，但发请求后断点不动、日志也不打——这大概率不是调试配置问题，是请求根本没走到那行代码。
- 检查中间件是否提前终止：比如
express.json()因 body 太大或格式错误直接返回 400，后续路由不会执行；建议先在中间件或app.use((err, req, res, next) => { ... })里设断点 - 确认
program指向的是实际被npm start执行的文件，常见坑是package.json里写的是bin/www，但launch.json还指向index.js - 端口冲突会导致进程静默退出：如果本地已有一个
npm run dev占着3000，新调试进程可能因EADDRINUSE崩溃，VSCode 看似“没反应”，其实是进程启动失败了
TypeScript 断点变空心红圈，sourceMap 没生效
你在 src/index.ts 上打了断点，但 VSCode 显示空心圆，说明它找不到对应的编译后代码或 map 文件。
- 必须同时满足三件事：
tsconfig.json开启"sourceMap": true、launch.json中启用"sourceMaps": true、且"outFiles"指向正确的构建输出目录（如"${workspaceFolder}/dist/**/*.js"） - 不要依赖
tsc --watch或构建工具自动触发；每次改完tsconfig.json或launch.json后，务必重新运行tsc生成新文件，再重启调试会话 - 如果用了
nodemon+ts-node，就别配sourceMaps和outFiles，直接把"program"指向.ts文件，并确保runtimeExecutable是ts-node路径
最常被忽略的一点：VSCode 调试器不会自动感知你改了 tsconfig.json 或删了 dist 目录，它只认当前 launch.json 的配置和磁盘上真实存在的文件。断点失效时，先看左下角状态栏有没有显示 “Source maps loaded”，没有就说明路径或生成环节断了。
