vscode复合调试需在launch.json顶层配置compounds字段，引用已定义的configurations名称；必须确保各子调试器就绪（如attach前启动服务、sourcemap正确），否则断点失效或静默失败。
复合调试任务在 launch.json 里怎么写
VSCode 的复合调试（compound）不是独立功能，而是通过 launch.json 中的 compounds 字段把多个已定义的 configuration 组合起来启动。它本身不启动任何进程，只负责协调——所以必须先有至少两个有效的 configurations，再在 compounds 里引用它们的名字。
常见错误是直接在 compounds 里写路径或参数，这会报错：Property "configurations" is missing 或 Unknown configuration type。
-
compounds必须放在launch.json顶层（和configurations同级），不能嵌套 - 每个
compound必须有name和configurations字段，configurations是字符串数组，值必须严格匹配已有configuration的name - 支持
preLaunchTask，但仅作用于整个复合任务，不是每个子配置单独触发
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Frontend",
"type": "pwa-chrome",
"request": "launch",
"url": "http://localhost:3000"
},
{
"name": "Debug Backend",
"type": "node",
"request": "attach",
"port": 9229
}
],
"compounds": [
{
"name": "Fullstack Debug",
"configurations": ["Debug Frontend", "Debug Backend"]
}
]
}
为什么 compound 启动后只有一个进程在调试
最常遇到的现象：点了「Fullstack Debug」，Chrome 打开了，但 Node 进程没连上，或者反过来。根本原因不是配置写错了，而是两个子调试器的启动时序/就绪状态不匹配。
比如 node 配置用了 "request": "attach"，但后端服务还没启动或没开调试端口，VSCode 就会静默失败，不报错也不提示；又比如前端 pwa-chrome 启动太快，页面加载完成前，后端接口还不可用，导致断点看似“没命中”。
- 用
"request": "launch"启动的配置（如 Node 脚本）要确保program路径正确、依赖已安装，否则直接退出，compound 不会阻塞等待 - 用
"request": "attach"的配置必须提前手动启动目标进程，并确认调试端口已监听（可用lsof -i :9229或netstat -an | grep 9229验证） - 没有内置的「等待依赖就绪」机制，想让前端等后端，得在前端代码里加重试逻辑，或用 shell 脚本包装启动顺序
Node + Chrome 复合调试的实际启动顺序怎么控
VSCode 默认并发启动所有 configurations，但真实开发中你往往需要「先起后端，等它 ready，再启前端」。这不是 compounds 能解决的，得靠外部协调。
推荐做法是把后端启动逻辑交给 tasks.json，用 preLaunchTask 触发，并配合 isBackground 和 problemMatcher 让 VSCode 知道它何时算“准备好”。
- 在
tasks.json中定义一个后端 task，设"isBackground": true，并配好problemMatcher匹配日志里的就绪提示（如Listening on http://localhost:8080） - 在
launch.json的Debug Backend配置里加"preLaunchTask": "start-backend" -
compound里仍写两个配置名，VSCode 会自动等 background task 就绪后再启动下一个 - 注意：Chrome 配置不要设
preLaunchTask，否则可能阻塞整个流程；它的就绪依赖后端，应由前端代码控制重试
调试器类型不一致导致断点失效
复合任务里混用不同调试器（比如 node + pwa-chrome + python）没问题，但断点行为完全独立——你在 Python 文件打的断点，不会影响 Node 或 Chrome 的执行流，反之亦然。容易误以为「断点没生效」，其实是调试器没 attach 到对应进程。
典型陷阱：给 TypeScript 后端配了 node 调试器，但源码映射（source map）没开启或路径不对，断点落在编译后的 .js 文件上，而 VSCode 显示的是 .ts，看起来像“断点变灰”。
- Node 项目务必在
tsconfig.json中启用"sourceMap": true和"inlineSources": true - Chrome 调试前端时，确保构建工具（如 Webpack/Vite）生成了正确的 source map，并在
pwa-chrome配置中设"sourceMaps": true - 不同调试器的
outFiles、webRoot、resolveSourceMapLocations等字段含义不同，不能复用同一组值
复合调试本身不增加复杂度，真正卡住人的永远是单个调试器的就绪条件和源码映射细节。
