断点不触发需先检查launch.json的type和request是否匹配运行环境，如node.js脚本应配"pwa-node"和"launch"；再确认sourcemaps、解释器路径、调试端口及条件断点语法等配置。
断点不触发？先确认 launch.json 的 type 和 request 是否匹配运行环境
VSCode 断点失效，八成卡在这一步。比如你用 Node.js 写脚本，launch.json 却配成了 "type": "pwa-node" 但 "request": "attach"，而实际是直接 node index.js 启动——这根本不会触发断点。必须选 "request": "launch"，且确保 "program" 指向入口文件的绝对路径或工作区相对路径（如 "${workspaceFolder}/src/index.js"）。
常见错误现象：Breakpoint ignored because generated code not found 或断点变空心圆。这时别急着重装插件，先检查：
• TypeScript 项目是否漏了 "sourceMaps": true 和 "outFiles" 配置
• Python 用户是否误用了 python 扩展的默认配置，却在 Poetry 环境下运行，导致解释器路径没对齐
• 前端项目用 Vite，type 必须是 "pwa-chrome" 或 "pwa-msedge"，不是 "chrome"（旧版已弃用）
debugger 语句和 VSCode 断点行为不一致？关键看是否启用 skipFiles
debugger 是运行时指令，VSCode 断点是调试器注入的暂停点，二者触发时机和条件不同。最常被忽略的是 skipFiles 配置：它默认会跳过 node_modules 和某些内置库，但如果你在 node_modules 里打了 debugger，它照样执行；而你在 VSCode 里给同一行打的断点，会被直接忽略。
实操建议：
• 调试依赖内部逻辑时，在 launch.json 中显式清空 skipFiles："skipFiles": []
• 不想全局跳过，又怕干扰，可用 "skipFiles": ["<node_internals>/**", "!**/my-dep/**"]</node_internals> 精确控制
• Chrome DevTools 中 debugger 可被禁用，但 VSCode 断点不受此影响——这是两个独立开关
多进程/子进程调试失败？attach 模式 + processId 不可靠，改用自动 attach
Node.js 的 child_process.fork()、Python 的 multiprocessing、甚至前端 Worker，都可能生成新进程。手动填 processId 在 launch.json 里几乎必败：PID 动态变化，且 VSCode 很难在子进程启动瞬间捕获。
更稳的做法：
• Node.js：启动主进程时加 --inspect-brk，并在子进程中用 execArgv: ['--inspect-brk=9230']，再配一个额外的 attach 配置指向该端口
• Python：用 ptvsd 或 debugpy，在子进程中调用 debugpy.listen(5678)，然后 VSCode 新建一个 attach 配置连过去
• 注意：所有跨进程调试必须确保目标进程的调试端口未被占用，且防火墙/容器网络允许本地连接
条件断点写错语法？condition 字段只接受 JavaScript 表达式，不是字符串
VSCode 条件断点的 condition 字段（右键断点 → Edit Breakpoint → Condition）本质是 JS 求值表达式，不是字符串模板。写成 "item.id === 123"（带引号）就永远不触发；正确写法是 item.id === 123（无引号）。
容易踩的坑：
• 访问未定义变量会静默失败，断点照常触发——建议先在 Debug Console 里测试表达式
• 异步代码中用 this 可能指向错误上下文，优先用闭包变量或显式参数
• 正则字面量要双反斜杠：/^error/.test(msg) ✅，/^error/.test(msg) ❌（复制粘贴时容易丢转义）
• 太重的条件表达式（如遍历大数组）会显著拖慢调试速度，宁可拆成普通断点+Debug Console 手动判断
真正麻烦的从来不是设断点，而是搞清「当前停在哪一层堆栈、变量作用域是否被优化、源码映射是否对得上」。这些细节藏在 launch 配置、运行时参数、甚至编译工具链里，而不是断点图标有没有实心。
