VSCode中"${fileDirname}/*.c"在Windows上失败，因cmd不展开通配符，gcc收到字面字符串而非文件列表；应改用PowerShell显式调用、硬编码文件名或优先使用Makefile管理依赖与构建。
VSCode 本身不运行文件，它只执行你明确告诉它的命令；所谓“运行多个文件”，本质是让构建工具（如 make 或 cmake）把它们编译链接成一个可执行程序，再启动它。
tasks.json 里写 "${fileDirname}/*.c" 为什么在 Windows 上总失败？
因为 Windows 的 cmd.exe 不展开 * 通配符——gcc 实际收到的是字面字符串 "src/*.c"，不是一堆文件名。PowerShell 能展开，但 VSCode 默认用 cmd 启动任务。
- 别依赖 shell 展开：Windows 下直接写死文件列表或改用
make是更稳的选择 - 如果硬要用通配符，得显式切换 shell：
"options": {"shell": {"executable": "pwsh.exe"}}，但会引入 PowerShell 版本和编码兼容性问题 - 即使展开成功，
gcc *.c也不处理依赖：改了头文件，utils.c可能不会重编，导致静默链接旧目标文件
为什么推荐从 Makefile 开始，而不是直接改 tasks.json？
Makefile 解决的不是“怎么调 gcc”，而是“哪些该重编、什么时候重编”这个核心问题。VSCode 的 tasks.json 只负责调它、捕获错误、传给调试器。
-
Makefile中用$(wildcard *.c)或更稳妥的$(shell find src -name "*.c")动态收集源文件，新增io.c不用改任何配置 - 加
-include $(DEPS)和.c.d规则，让gcc -MM自动生成头文件依赖，改了utils.h就自动触发utils.o重编 -
tasks.json只需简单写："command": "make"、"problemMatcher": ["$gcc"]、"group": "build"，其他都交给 Makefile
launch.json 启动时提示 “找不到可执行文件”，常见原因有哪些？
根本原因是 program 字段路径和 Makefile 实际输出位置不一致。VSCode 不会猜测、也不会自动查找。
-
program必须和 Makefile 里gcc -o的目标路径完全匹配，例如 Makefile 写gcc *.c -o build/app.exe，launch.json就得写"program": "${workspaceFolder}/build/app.exe" - Windows 下必须带
.exe后缀，漏掉就找不着——Linux/macOS 不需要，但跨平台项目建议统一加后缀并用条件判断 - 务必配
"preLaunchTask": "make"，且tasks.json中对应任务的label是"make"（严格大小写、无空格） - 如果 Makefile 在
src/子目录，tasks.json要设"options": {"cwd": "${workspaceFolder}/src"}，否则make找不到它
真正容易被忽略的点是：Makefile 里没写 .PHONY: clean 或没用 rm -f，会导致中间文件残留，掩盖真正的编译失败；而 VSCode 的 problemMatcher 只解析标准 gcc 输出格式，自定义 echo 或非标准错误信息不会跳转——这些细节一漏，调试就卡在“明明改了代码却没生效”的状态里。
