VSCode断点不触发主因是调试配置与运行环境不匹配：需确认launch.json的type、program路径、sourceMaps及preLaunchTask是否正确，区分launch/attach模式，合理配置skipFiles和端口。
断点不触发？检查调试配置是否匹配运行环境
vscode 的断点不生效，八成是 launch.json 配置和实际执行方式对不上。比如用 node index.js 启动，但 launch.json 里设的是 program 指向 src/index.ts，且没配 typescript 编译——断点自然不会停在源码上。
- 确认
type字段：Node.js 项目填"node"，Chrome 调试填"pwa-chrome"，TypeScript 项目必须加"preLaunchTask": "tsc: build - tsconfig.json"或启用sourceMaps: true - 检查
program路径是否为实际入口文件（如"${workspaceFolder}/dist/index.js"），不是 TS 源码路径，除非已生成正确 source map - 若用
npm run dev启动（如 nodemon、ts-node），需改用attach模式，而不是launch；否则 VSCode 会另起一个进程，和你的终端进程无关
调试控制台输不出变量？注意作用域与求值时机
在断点暂停后，调试控制台（Debug Console）输入 user.name 报 ReferenceError，往往不是变量不存在，而是当前执行上下文里它还没声明、已被释放，或属于闭包外层作用域。
- 只允许访问「当前堆栈帧」可见的变量；函数参数、
let/const声明的局部变量在退出作用域后无法访问 -
console.log()输出的内容 ≠ 调试控制台可访问内容：后者走的是 V8 的 debug protocol 求值，受严格作用域限制 - 想强制查看闭包变量，可在断点处右键变量 →
Add to Watch；Watch 窗口比 Debug Console 更稳定，支持延迟求值
修改代码后继续调试就跳过断点？热重载未同步调试状态
用 nodemon 或 ts-node --files 开发时，文件保存触发重启，但 VSCode 的调试会话仍连着旧进程，新代码的断点不会被识别，表现为“断点变空心”或“跳过不暂停”。
- 不要依赖自动重启；改用
attach模式配合nodemon --inspect-brk：先启动带调试端口的服务，再让 VSCode 连上去 -
launch.json中设置"restart": true仅对launch模式有效，且只适用于进程退出后自动重启，不适用于热更新场景 - 常见错误配置：
"port": 9229写死，但nodemon --inspect-brk默认用 9229，而node --inspect可能用 9229~9239 动态端口；建议统一显式指定端口并关闭端口复用
{
"type": "node",
"request": "attach",
"name": "Attach to Process",
"port": 9229,
"address": "localhost",
"restart": true,
"sourceMaps": true,
"outFiles": ["${workspaceFolder}/dist/**/*.js"]
}为什么 step into 总跳进 node_modules？忽略规则没生效
按 F11（Step Into）想进入自己写的函数，结果一头扎进 lodash.merge 或 express 内部，说明 skipFiles 或 smartStep 没起作用。
- 优先用
"skipFiles"：填 glob 模式，如["<code>**/node_modules/**"]，注意路径分隔符统一用/（Windows 下也如此） -
"smartStep": true是辅助项，只对“明显非业务代码”的单步做跳过，不可靠；必须配合skipFiles才稳定 - 某些库（如 ESM 包）可能因 source map 路径异常导致 skip 失效；可临时在
skipFiles加更精确路径，如"**/node_modules/lodash-es/**"
断点和调试控制台本身很轻量，真正卡住人的，往往是配置和运行模式之间的隐性错位。尤其在混合使用构建工具、转译器、进程管理器时，得先确认「VSCode 连的是哪个进程」「这个进程加载的是哪份代码」「source map 是否指向原始位置」——这三个问题没理清，调得再细也没用。
