F5调试前不清理中间文件，是因为preLaunchTask仅执行命令而不自带清理语义；若tasks.json中任务未显式包含rm -rf build/等清理指令，.o、.d及build/目录将残留，导致链接旧目标文件、行为不可控。
F5 调试前不清理中间文件，不是配置漏了，而是 preLaunchTask 默认不带清理语义——它只执行命令，不管你是覆盖还是追加、删不删旧.o/.d/.build。
preLaunchTask 为什么没清掉 .o 和 build/ 目录？
launch.json 里的 preLaunchTask 字段只是“调用一个 label 匹配的任务”，它不关心这个任务干了什么。常见错误是：配了个 "label": "build" 的 task，里面只写了 g++ main.cpp -o main，这确实能生成新可执行文件，但 .o、.d、build/ 全都原封不动留在磁盘上。
后果很直接：下次改了头文件但没改 main.cpp，编译器可能跳过重编译，链接时却用了旧的 util.o，行为和预期不符。
-
preLaunchTask不等于 “clean + build”——它只是个标签匹配器，不是构建语义封装器 - 如果你的 task 没显式写
rm -rf build/或del /f *.o，它就不会删 - 别指望
make clean && make自动生效：没Makefile或clean:规则写错（比如漏了-前缀），make clean就静默失败
tasks.json 里怎么写一个真正能清的 build 任务？
关键不是“多高级”，是“顺序可控 + 失败即停”。用 && 连接命令是最轻量可靠的方案，尤其对 C/C++、Rust、Go 这类无构建缓存依赖的项目。
以 Linux/macOS 为例，.vscode/tasks.json 中这样写：
{
"version": "2.0.0",
"tasks": [
{
"label": "clean & build",
"type": "shell",
"command": "rm -rf build/ && mkdir -p build && g++ -c main.cpp -o build/main.o && g++ build/main.o -o build/main",
"group": "build",
"presentation": {
"echo": true,
"reveal": "always",
"panel": "shared",
"clear": true
},
"problemMatcher": ["$gcc"]
}
]
}
-
rm -rf build/必须放在最前，且用&&连接后续命令——任一环节失败（比如权限不足），整个 task 终止，不会留下半截产物 - Windows 用户把
rm -rf换成cmd /c "rmdir /s /q build 2>nul && mkdir build"，注意2>nul吞掉目录不存在时的报错，否则命令链中断 -
"group": "build"是必须的，否则Ctrl+Shift+B找不到默认任务，preLaunchTask也匹配不到 - 别用
type: "process"写清理逻辑——它不支持&&和管道，rm和mkdir得拆成两个 task 再用dependsOn，反而更重
launch.json 怎么确保 F5 一定跑 clean & build？
就一条：在 .vscode/launch.json 的配置项里，加准确匹配的字符串：
"preLaunchTask": "clean & build"
注意这几点：
- 字符串必须和
tasks.json里label完全一致，包括空格、符号、大小写——写成"Clean & Build"或"clean&build"都会静默失败 - 如果项目有多个
build类任务，VSCode 不会自动选“带 clean 的那个”，它只认字面匹配 - 改完
tasks.json后不用重启 VSCode，但建议按Ctrl+Shift+P→ 输入Tasks: Run Task回车，确认clean & build出现在列表里，避免路径或语法错误导致加载失败
为什么不用 dependsOn 写 clean + build 分离任务？
可以，但没必要——除非你明确需要复用 clean 任务（比如单独绑定快捷键或 CI 脚本调用）。对绝大多数单项目调试场景，合并在一个 task 里更可靠。
分离写法的问题很实际：
- 如果
clean任务里漏了"isBackground": false，VSCode 可能认为它“还没结束”，build就卡住不启动 - 如果
clean任务失败（比如rm权限不够），dependsOn默认仍会执行build，得不到“失败即停”的保障 - 多一层配置，就多一层出错点：
label拼错、dependsOn数组写成字符串、group没统一……排查起来比单行rm && g++慢得多
真正复杂的地方在于路径和平台差异：Linux 的 rm -rf、Windows 的 rmdir /s /q、macOS 上 zsh 对通配符的处理，这些细节一旦写错，清理就失效——而它不像语法错误那样报红，你得靠 ls build/ 或 dir build 手动验证。
