preLaunchTask 必须严格匹配 tasks.json 中 task 的 label；依赖顺序由 dependsOn 控制，支持自动触发链式任务；它仅在调试启动时运行一次，不检测文件变更；失败时需查看 TERMINAL 输出而非 DEBUG CONSOLE。
launch.json 的 preLaunchTask 字段必须匹配 tasks.json 中的 label
VSCode 调试启动顺序不是靠“自动排队”，而是靠 preLaunchTask 显式声明依赖。如果你希望先编译再调试，preLaunchTask 的值必须和 tasks.json 里某个 task 的 label 完全一致——大小写、空格、标点都不能差。
常见错误现象：preLaunchTask 写成 "build"，但 tasks.json 里实际是 "C/C++: gcc build Debug version"，结果调试直接跳过编译，跑的是旧二进制；或者写成 "build-debug" 却漏了连字符，VSCode 提示 “Task not found”。
实操建议：
-
preLaunchTask值建议用简短、无空格的字符串（如"build"），并在tasks.json中显式设为对应 task 的label - 多个前置任务不支持链式写法（比如不能写
["clean", "build"]），只能指定一个；如需多步，把 clean 和 build 合并进一个 shell task - 如果 task 有
dependsOn（比如"dependsOn": ["createBuildDir"]），它会在preLaunchTask执行时自动触发依赖链，无需额外配置
tasks.json 里的 dependsOn 是真正的执行顺序控制点
dependsOn 是 VSCode 任务系统里唯一能定义执行先后关系的字段。它不是“建议执行”，而是硬性依赖：父 task 不开始，子 task 就不会运行；子 task 不完成，父 task 就卡住。
使用场景：C/C++ 项目中，build task 必须等 createBuildDir 先建好 build/Debug 目录；Python 项目中，pip install -e . 必须在 pytest 运行前完成。
实操建议：
- 确保
dependsOn引用的 task 存在且拼写完全一致，否则整个 task 链会静默失败（VSCode 不报错，但目录没建、编译没跑） - 避免循环依赖，比如 A 依赖 B，B 又依赖 A —— VSCode 会卡死在“正在解析任务依赖”状态
- 如果 task 是
shell类型（如 mkdir），记得加-p参数，防止目录已存在时报错中断
preLaunchTask 不会重编译，只运行一次
按 F5 启动调试时，preLaunchTask 仅在本次调试会话开始前执行一次。修改代码后再次按 F5，它不会自动检测文件变更、也不会跳过未改动的源码——它只是原样再跑一遍那个 task。
这意味着：如果你改了 main.c 但没手动保存，或 task 里用的是 ${file} 而你当前打开的是其他文件，编译的就不是你预期的源码。
实操建议：
- 调试前务必手动保存所有修改（Ctrl+S），尤其注意未激活的编辑器标签页
- task 的
args中慎用${file}，优先用固定路径如"${workspaceFolder}/src/main.c"，避免因焦点切换导致编译错文件 - 如果需要“保存即编译”，得另配文件监视器（如
watchtask +onSave触发），preLaunchTask本身不具备该能力
调试启动失败时，先看终端输出而非断点是否生效
很多人一看到断点没停，就去翻 sourceMaps 或检查路径，但真正卡在启动顺序上的问题，往往出现在终端里：比如 gdb 启动失败、python 找不到模块、link.exe 报找不到 io.lib。这些错误在调试控制台（DEBUG CONSOLE）里看不到，必须切到 TERMINAL 标签页，选 Tasks 或 Debug 分组查看原始输出。
容易被忽略的地方：
-
preLaunchTask失败时，VSCode 默认仍会尝试启动调试器（比如直接跑./outDebug），但此时二进制可能根本不存在或已损坏 - Windows 下若 task 调用的是
cmd命令（如mkdir），而终端默认是 PowerShell，可能因执行策略报错，需在tasks.json中显式指定"type": "shell"并加"command": "cmd /c mkdir" - 某些 task 输出含中文或特殊字符时，终端编码可能错乱，导致后续调试器读取路径失败（如把
build\Debug解析成乱码路径），建议统一用英文路径
