简介：这份Word教程面向Windows平台初次接触VSCode的C/C++学习者，也适合需要补齐环境配置的编程课程学生与自学者。内容围绕编辑器安装、中文界面切换、MinGW-w64编译器部署、系统环境变量设置、C/C++插件启用以及编译调试任务配置等常见难点展开，帮助读者从零建立可编写、可编译、可运行的C/C++基础开发环境。文档还包含初学者工具选型提醒，说明何时更适合使用Visual Studio或Dev-C++，并针对项目路径含中文导致调试失败等问题给出排错思路。整包仅含1份docx文档，约7.46MB，以图文步骤、配置片段和注意事项组织，便于按章节查阅与对照实践，适合希望系统掌握VSCode基础配置流程的读者。目前已有1486人学习，适合课程学习、自学入门或机房环境搭建时参考，也能帮助读者梳理插件、编译器路径与任务配置之间的关系，减少反复试错。
1. 环境搭好了却跑不起来：Windows 上 VSCode 配 C/C++ 最常见的三个拦路虎
在 Windows 上用 VSCode 搭 C/C++ 开发环境，真正劝退人的从来不是语法，而是编译器装完、插件装完、代码一个字没错，按下 F5 却弹出一行红字：preLaunchTask "C/C++: gcc.exe 生成活动文件" 已终止，退出代码: 1。这类故障最气人的地方在于「看起来像代码问题，实际全是环境问题」——报错指向第 12 行，根因却在 PATH 里；tasks.json 改到半夜，真正出错的是文件夹名字带了个中文。
做 VSCode + C/C++ 环境搭建的人几乎都会撞上这几堵墙：命令行提示 gcc 不是内部或外部命令、编译能过但断点是空心圆、单个文件正常多文件就 undefined reference、生成 exe 时报 Permission denied。下面按「编译器能不能找到 → 路径能不能认 → 配置有没有生效 → 冲突怎么排」逐层拆，每条都给到能直接抄的命令和配置。
2. 提示「gcc 不是内部或外部命令」：MinGW 装完却找不到编译器的四种情况
2.1 PATH 改了，集成终端用的还是旧环境
现象很典型：系统变量里明明加了C:\mingw64\bin，层层点确定退出去，也在 VSCode 里按Ctrl + \`` 打开了终端，敲gcc -v` 得到的却是「无法将“gcc”项识别为 cmdlet、函数、脚本文件或可运行程序的名称」。可你把同一个命令拿到刚开的 PowerShell 窗口里试，又一切正常。
根因在于 Windows 的进程环境变量继承机制：每个进程在启动时从父进程复制一份环境变量快照，之后系统变量再怎么改，已经跑起来的进程都看不见。VSCode 如果在你改 PATH 之前就开着，它和它拉起来的集成终端用的就是那份旧快照。点右上角叉号很多时候只是把窗口关掉，进程还在后台，重开一次仍然继承旧的。
解决方式只有一条：彻底退出 VSCode 再启动。任务栏图标右键退出，或者干脆重启资源管理器。先用下面三行命令把「到底有没有生效」确认清楚，再去动别的文件。
# 1. 看当前会话的 PATH 里有没有 mingw 的 bin 目录，没输出就是没生效 $env:Path -split ';' | Select-String -Pattern 'mingw' # 2. 问系统 gcc 实际解析到哪个文件（必须写 where.exe，PowerShell 里 where 是 Where-Object 的别名） where.exe gcc where.exe g++ # 3. 让编译器自报家门，顺便看它内置的头文件和库搜索路径 gcc -v第一行没有输出，说明 PATH 没被这个进程读到，回去重开 VSCode；第二行有输出但编译器仍报错，说明 PATH 里更靠前的位置有同名程序抢了位置，把C:\mingw64\bin往上挪。第三行是后面所有排查的地基，gcc -v的末尾会打印Target和Thread model，出问题时把这段贴出来，比贴任何报错都管用。
顺带提醒一个容易忽略的点：where在 PowerShell 里默认解析成Where-Object，直接敲where gcc会得到一堆莫名其妙的管道报错，很多新手就在这里被带偏，以为是环境没配好。记住写where.exe。
2.2 解压多套了一层，bin 不在你以为的位置
现象：PATH 里写的是C:\mingw64\bin，where.exe gcc却什么都查不到，但打开资源管理器一看，C:\mingw64下面确实有个bin文件夹。
根因是压缩包内层往往自带一层同名目录，解压出来的实际结构是C:\mingw64\mingw64\bin，多套了一层。你按直觉写的 PATH 指向了一个空壳目录，系统当然找不到编译器。这种事在下载站打包的压缩包里特别常见，因为对方打包时是连着顶层文件夹一起压的。
# 看 C:\mingw64 第一层到底有什么，正常情况下应该能直接看到 bin Get-ChildItem C:\mingw64 # 不确定 gcc.exe 落在哪，直接全盘定位它的真实路径，把 PATH 指到它的上一级目录 Get-ChildItem C:\ -Filter gcc.exe -Recurse -ErrorAction SilentlyContinue | Select-Object -First 5 FullName第二条命令会递归扫盘，慢是慢，但结果不含糊。拿到...\mingw64\bin\gcc.exe这样的绝对路径后，PATH 里要加的是bin这一层，不是gcc.exe本身，也不是它的上上级。改完依然要走一遍「彻底退出 VSCode → 重开 → where.exe gcc」的流程，否则你测的还是旧环境。
2.3 路径里有空格、中文、括号
现象比前两个更隐蔽：编译器能找到，gcc --version也正常，但一编译就报gcc: error: CreateProcess: No such file or directory，或者链接阶段提示找不到某个.o文件，而这个中间文件明明刚生成过。
根因是编译过程中工具链内部会拼接路径、创建临时文件，路径里出现空格或非 ASCII 字符时，某些环节的引号处理没兜住，字符串被截断成两段，于是「文件不存在」。Program Files (x86)这种带空格和括号的目录是重灾区，中文用户名下的「桌面」「下载」也是。
# 逐条检查 PATH 里跟 mingw 相关的路径，标出含空格或非 ASCII 字符的 ($env:Path -split ';') | Where-Object { $_ -match 'mingw' } | ForEach-Object { if ($_ -match '[^\x00-\x7F]') { "含非 ASCII：$_" } elseif ($_ -match ' ') { "含空格：$_" } else { "OK：$_" } }最省事的做法是直接放到C:\mingw64或D:\tools\mingw64这种短路径下，别为了「看起来整齐」塞进用户目录。挪完别忘了 PATH 也要跟着改，并且把旧路径删掉，别留两条。
2.4 装完不做验证，直接去写代码
这一步看着啰嗦，实际能省掉后面八成的返工。我一般会在写第一行代码之前，把下面四条挨个跑一遍，全绿了再打开 VSCode。
| 检查项 | 命令 | 正常表现 | 异常时先看哪里 |
|---|---|---|---|
| PATH 是否生效 | $env:Path -split ';' | Select-String mingw | 输出包含C:\mingw64\bin | 重开 VSCode，或重启资源管理器 |
| 编译器能否解析 | where.exe gcc | 输出一个.exe绝对路径 | 解压层级是否多套了一层 |
| 版本是否可执行 | gcc --version | 打印版本行 | 路径是否含空格或中文 |
| C++ 是否也在 | g++ --version | 同样打印版本行 | 是否只配了 gcc 没配 g++ |
这四条没过关之前，别去碰tasks.json。很多人的「配置问题」其实卡在这一层，改上一整天 JSON 也不会有任何变化，因为 VSCode 根本就没有编译器可调。
3. 编译能过、调试却莫名中断：中文路径和中文用户名埋的雷
3.1 报错信息里根本看不到「中文」两个字
这类故障最坑的地方是它不会直说原因。表现有好几种：tasks.json配好后编译无报错、exe 也生成了，但一按 F5 调试器起不来；或者断点变成空心圆，鼠标悬上去提示「未绑定断点」；或者 gdb 输出一堆乱码路径后直接退出；还有的在编译阶段就报No such file or directory，而它指向的那个文件你亲眼看着就在那儿。
根因是整条链路都在传绝对路径字符串：VSCode 展开变量 → 拼进命令行 → gcc/g++ 读取源文件 → gdb 加载符号表。每一环对编码的假设并不一致——编辑器按 UTF-8 传，Windows 控制台和部分工具链按当前代码页解析，路径一对不上，文件自然就「不存在」。调试环节对此更敏感，因为 gdb 要按路径去匹配源码和符号，路径匹配失败，断点就无法绑定到行号，表现出来就是空心圆，或者干脆一路跑完不暂停。
最常见的踩法是：工程放在「桌面」，而用户名是中文，真实路径就成了C:\Users\张三\Desktop\test_vscode。很多人只注意到工程文件夹名是英文，却没意识到上层目录里还藏着中文。项目正文里那句「保证创建的文件夹中的路径是没有中文名，不然后续会有一系列问题，就比如调试莫名报错」，说的就是这个。当初我配环境时也是在这卡了大半天，一直以为是调试器坏了。
3.2 一分钟把非 ASCII 字符揪出来
不用猜，直接用命令把整条绝对路径过一遍。
# 换成你自己的工程路径，检查整条路径有没有非 ASCII 字符或空格 $proj = "C:\Users\张三\Desktop\test_vscode" $proj if ($proj -match '[^\x00-\x7F]') { "路径含非 ASCII 字符，必须换位置" } if ($proj -match ' ') { "路径含空格，建议换位置" } # 顺便确认当前用户目录本身是不是中文名，这是最容易被忽略的一层 $env:USERPROFILE判断逻辑很直白：[^\x00-\x7F]匹配任何非 ASCII 字符，中文、全角符号都会被它抓到。第一段输出「必须换位置」就别犹豫了，这不是改配置能绕过去的。第二段如果USERPROFILE本身就是中文，那意味着你把工程放在桌面、文档、下载这些位置时，整条路径必然是中文的，只能换盘符或换根目录。
3.3 解决：挪到短英文路径，并清掉旧配置残留
步骤不复杂，但顺序不能乱，尤其是第三步，漏了等于白挪。
- 新建一个全英文、无空格、层级浅的目录，比如
D:\code\test_vscode。 - 把源码拷过去，用 VSCode 的「打开文件夹」重新打开这个新目录，不要在原窗口里改路径。
- 检查旧目录里的
.vscode是否残留了绝对路径，有就删掉重新生成。 - 重新跑一次编译和调试。
# 建立干净的工程目录，把源码搬过去（按你实际的文件类型调整通配符） New-Item -ItemType Directory -Force -Path D:\code\test_vscode | Out-Null Copy-Item -Path "$env:USERPROFILE\Desktop\test_vscode\*.c" -Destination D:\code\test_vscode # 检查新目录下的配置文件里还有没有非 ASCII 字符残留 Select-String -Path D:\code\test_vscode\.vscode\*.json -Pattern '[^\x00-\x7F]'第二条命令之所以必要，是因为c_cpp_properties.json里的compilerPath和tasks.json里的command、-o输出路径都可能是手写或从别处粘过来的绝对路径。工程挪了位置，这些字符串还指着旧地方，编译时就会报找不到文件，而你以为问题已经解决了。搜不到任何输出才是干净的状态。
3.4 位置实在挪不动时的兜底
有些场景工程必须待在某个目录里，比如共享盘、课程指定的提交目录，这时候就别硬碰路径了，改成「编译在短路径，产物再拷回去」：把源码同步一份到D:\code\下编译调试，确认没问题后把源码文件覆盖回原目录。听起来笨，但比跟编码问题纠缠一晚上划算。
另外不建议为了这个去动 Windows 的「Beta 版 UTF-8 支持」开关。那个开关会改变整个系统的默认代码页行为，可能让原本正常的控制台程序开始乱码，属于拆东墙补西墙。路径问题就在路径层面解决，别上升成系统级改动。
提示：判断是不是路径问题有一个土办法——同样的代码、同样的配置，复制到
D:\code\test这种路径下再编一次。如果那边一切正常，问题百分百出在原路径上，不用再怀疑编译器或插件。
4. 单文件能跑、多文件就 undefined reference：tasks.json 与 c_cpp_properties.json 改哪里
4.1 先分清两个 JSON 的分工，别在错的文件里使劲
这是我认为最值得先讲清楚的一点：c_cpp_properties.json只负责编辑器的智能提示，包括红波浪线、补全、跳转定义，它完全不参与编译。真正决定 gcc/g++ 怎么被调用、编译哪些文件、产物叫什么的，是tasks.json。
于是就有了最常见的死循环：编译报错 → 以为是配置不对 → 去改includePath→ 波浪线消失了 → 一编译还是同样的错。改到天亮也不会有效果，因为那个文件根本没进编译流程。
| 文件 | 谁在读它 | 影响什么 | 配错时的典型表现 |
|---|---|---|---|
c_cpp_properties.json | C/C++ 插件 | 智能提示、跳转、语法检查 | 头文件标红，但能正常编译 |
tasks.json | VSCode 任务系统 | 调用哪个编译器、编译哪些文件、产物路径 | 编译报错、链接报错、找不到 exe |
launch.json | 调试器 | 调试哪个 exe、用哪个 gdb | F5 起不来、断点不命中 |
记住一句话：红波浪线找第一个，编译报错找第二个，F5 报错找第三个。
4.2 undefined reference：args 里只写了${file}
现象很明确：单文件编译运行一切正常，一旦把函数拆到另一个.c文件里，链接阶段就报undefined reference to 'xxx'，而那个函数的定义你翻来覆去确认过确实存在，头文件也 include 了。
根因是tasks.json的args里写的是${file}。这个变量只展开成当前活动文件，也就是你正在编辑的那一个。另一个.c压根没参与编译，链接器自然找不到它的实现。单文件的时候看不出问题，因为「所有代码」正好就是当前文件。
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: gcc.exe 生成活动文件", "command": "C:\\mingw64\\bin\\gcc.exe", "args": [ "-fdiagnostics-color=always", "-g", "${workspaceFolder}\\*.c", "-o", "${workspaceFolder}\\${workspaceRootFolderName}.exe" ], "options": { "cwd": "${workspaceFolder}" }, "problemMatcher": ["$gcc"], "group": { "kind": "build", "isDefault": true }, "detail": "编译器: C:\\mingw64\\bin\\gcc.exe" } ] }改动就集中在两个地方：把${file}换成${workspaceFolder}\\*.c，让目录下所有 C 源文件一起参与编译链接；把-o的输出改成固定名字${workspaceFolder}\\${workspaceRootFolderName}.exe，产物名跟文件夹同名，不会因为切了活动文件就变成另一个 exe。cwd设成工作区根目录，保证相对路径的解析基准稳定。
-g这个参数单独强调一下：它负责生成调试信息，没有它，gdb 拿不到行号映射，断点就是空心圆，F5 会一路跑完不停。很多人编译用的是默认任务，压根没带-g，然后抱怨调试器不好使。
常用变量的含义整理在下面，改配置时对着看就行：
| 变量 | 展开结果 | 适用场景 |
|---|---|---|
${file} | 当前活动文件的绝对路径 | 只编单文件 |
${workspaceFolder} | 打开的文件夹根目录 | 多文件工程 |
${fileDirname} | 当前文件所在目录 | 输出到源文件旁边 |
${fileBasenameNoExtension} | 当前文件名（不含扩展名） | 按文件分别产出 exe |
${workspaceRootFolderName} | 工作区文件夹名 | 产物与工程同名 |
还有两个容易翻车的细节。第一，tasks.json支持//注释（它是 jsonc 格式），但如果你把内容拷进一个严格的.json文件里就会解析失败；从别处粘配置时记得把注释清掉。第二，别用同一个任务同时编 C 和 C++：gcc编.cpp不会自动链接 C++ 标准库，会报一堆undefined reference to std::...；混编工程的正确做法是先用gcc -c和g++ -c分别编译成.o，再用g++统一链接。
4.3c_cpp_properties.json里真正要改的只有两行
这个文件在项目正文里也给了，内容看着长，实际跟 MinGW 场景相关的就compilerPath和intelliSenseMode两项。
{ "configurations": [ { "name": "Win32", "includePath": ["${workspaceFolder}/**"], "defines": ["_DEBUG", "UNICODE", "_UNICODE"], "compilerPath": "C:/mingw64/bin/gcc.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "gcc-x64" } ], "version": 4 }compilerPath必须指向真实存在的编译器可执行文件，插件靠它去问编译器要内置宏和头文件搜索路径，路径写错，编辑器就会用一套猜测的默认值，结果就是标准库头文件全标红。intelliSenseMode要和编译器匹配，用 MinGW 就写gcc-x64，写成别的会让补全和实际编译行为对不上。includePath里的**表示递归包含工作区所有子目录，一般不用动。
windowsSdkVersion这一行对 MinGW 场景基本没有影响，留着也不会出错，但别指望它解决任何问题。改完这个文件之后如果波浪线还在，别急着重装插件，先执行一次命令面板里的C/C++: Reset IntelliSense Database，或者直接重载窗口，让插件重新读一遍配置。
4.4 F5 报preLaunchTask 已终止：label 对不上或没设默认
现象是按 F5 直接弹出错误框，写着某个任务已终止，退出代码 1，但你在终端里手动跑生成任务又是成功的。
根因通常有两个：launch.json里preLaunchTask的字符串和tasks.json里label的值不完全一致（多一个空格、少了C/C++:前缀都算不一致）；或者构建任务没有标成默认构建任务，F5 触发时挑了另一个。
{ "version": "0.2.0", "configurations": [ { "name": "gcc.exe - 生成和调试活动文件", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}\\${workspaceRootFolderName}.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:\\mingw64\\bin\\gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: gcc.exe 生成活动文件" } ] }三个关键点：preLaunchTask的值必须和tasks.json里的label逐字符相同；program必须和tasks.json里-o的输出路径一致，否则调试器会去找一个不存在的 exe，报「找不到指定文件」；miDebuggerPath指向 gdb，MinGW 的 bin 目录里自带，不需要单独装。externalConsole设为false让程序跑在集成终端里，好处是能直接看到输出，坏处是遇到scanf之类的输入时偶尔会有回显问题，真碰上了再改成true。
5. 避坑清单：五个能把人按在椅子上三小时的报错
5.1cannot open output file test.exe: Permission denied
现象：上一次还能正常编译，这次什么都没改，突然报cannot open output file ...\test.exe: Permission denied，或者ld returned 1 exit status。
原因：上一次运行的 exe 进程还没退出，Windows 对正在执行的可执行文件加了文件锁，链接器无法覆盖写入。常见触发场景是程序里有死循环、或者用了getchar()之类的阻塞调用，你关了终端窗口但进程残留在后台。另一种可能是安全软件把新生成的 exe 当成可疑文件当场隔离了。
解决：先把残留进程结束掉，再重新编译。
# 按进程名结束残留的可执行文件（把 test 换成你的产物名，不带 .exe） Get-Process test -ErrorAction SilentlyContinue | Stop-Process -Force # 确认目录下没有锁住的产物，能删掉说明锁已经释放 Remove-Item .\test.exe -ErrorAction SilentlyContinue如果结束进程后立刻又能编译，那就是这个原因；如果反复出现，把工程目录加进安全软件的信任列表，别每次都靠手动杀进程。
5.2 终端里 printf 中文全是乱码
现象：源码文件是 UTF-8，编译没有任何警告，运行后中文输出变成一串问号或者「锟斤拷」。
原因：源文件编码和控制台输出编码不一致。Windows 控制台默认代码页是 936（GBK），而 gcc 默认按 UTF-8 处理源文件里的字符串字面量，两边对不上就乱码。
解决：两种做法，选一种即可。临时方案是在终端里先切代码页：
# 把当前终端切到 UTF-8 代码页，只对当前窗口有效 chcp 65001长期方案是在tasks.json的args里加一个参数，让编译器直接把字符串转成控制台认识的编码：
"args": [ "-fdiagnostics-color=always", "-g", "-fexec-charset=GBK", "${workspaceFolder}\\*.c", "-o", "${workspaceFolder}\\${workspaceRootFolderName}.exe" ]-fexec-charset控制的是可执行文件里字符串的运行期编码。加完之后重新编译，输出就正常了。不建议去改源文件编码来迁就控制台，那会影响跨平台和版本管理。
5.3 断点是空心圆，F5 一路跑完不暂停
现象：断点打上去显示成灰色空心圈，鼠标悬停提示未绑定；按 F5 程序直接跑完退出，完全没有停下来。
原因：三条都可能——编译时没带-g，exe 里没有调试信息；launch.json的program指向了另一个旧的 exe；或者工程路径有中文导致路径匹配失败（见第 3 章）。
解决：先确认tasks.json的args里有-g，再看launch.json的program是不是和-o的输出一致，最后检查路径。三者都对还是不行，删掉.vscode整个目录重新生成一遍，比逐个字段排查快。
5.4 改完tasks.json，编译行为一点没变
现象：明明把${file}改成了${workspaceFolder}\\*.c，重新编译还是只编当前文件，多文件照样 undefined reference。
原因：工程里存在不止一份tasks.json——工作区的.vscode/tasks.json和用户级的任务配置同时在，VSCode 可能选中了另一份；或者终端面板里手动执行的是上一次的任务，而不是你刚改的那条。
解决：用Ctrl + Shift + P打开命令面板，执行Tasks: Run Task，看清列表里到底有几条同名任务，选带工作区标识的那条。同时在资源管理器里确认.vscode目录就在你当前打开的文件夹根目录下，而不是在某个子目录里。改完配置后重载一次窗口，别指望它热更新。
5.5 装了中文语言包，界面还是英文
现象：扩展市场里搜 Chinese，装了排在最上面的那个，右下角弹了提示框，点了个关闭，界面纹丝不动。
原因：语言包需要重启才生效，弹框里的 Restart 按钮点掉之后就默认维持在英文界面了。
解决：Ctrl + Shift + P执行Configure Display Language，选中文，它会提示重启编辑器。如果列表里根本没有中文选项，说明语言包装到了别的用户环境或者装失败了，回扩展面板确认一下状态，卸载重装。
注意：五条里有三条的共同点是「改了没生效」。养成习惯——凡是改了
.vscode下的配置、环境变量、插件，一律重载窗口或彻底重启编辑器之后再验证，否则你测的永远是旧状态。
6. 快速定位：三步判断问题卡在编译器、配置还是代码
踩过足够多次之后，我形成了一个固定顺序，基本上三分钟内能确定问题在哪一层，不用在几个文件之间反复横跳。
第一步，绕过 VSCode，直接在终端里手敲编译命令。这一刀切下去，立刻就能分出「编译器的问题」还是「VSCode 配置的问题」。
# 进入工程目录，完全绕开 tasks.json，手动调一次编译器 cd D:\code\test_vscode gcc -g *.c -o test.exe # 编译成功就立刻跑一遍，确认产物本身没问题 .\test.exe如果手动命令能编过、能运行，说明编译器和环境都是好的，问题百分百出在tasks.json或launch.json的字段上，按照第 4 章的顺序查command、args、-o、cwd四项即可。如果手动命令也失败，那就是第 2、3 章的问题——先去查 PATH 和路径编码，别碰 JSON。
第二步，看 VSCode 终端面板里打印的完整命令行。任务执行时，终端里会把实际调用的命令原样打出来，包括所有展开后的绝对路径。把这行和你手动敲的那行逐字符对比，差异往往一眼就能看出来：可能多了个引号，可能路径里还是那个中文用户名，可能-o指向了别的目录。这一步最大的价值是让你看到「真实发生了什么」，而不是「你以为配置写了什么」。
第三步，按报错阶段对号入座。
| 报错阶段 | 典型信息 | 大概率的层 | 先验证什么 |
|---|---|---|---|
| 启动任务前 | preLaunchTask 已终止，退出代码 1 | 配置层 | preLaunchTask与label是否一致 |
| 调用编译器 | 无法将"gcc"项识别为… | 环境层 | where.exe gcc |
| 编译源文件 | No such file or directory | 路径层 | 绝对路径是否含中文或空格 |
| 链接 | undefined reference to ... | 配置层 | args里是否只写了${file} |
| 写产物 | Permission denied | 进程层 | 是否有残留进程占着 exe |
| 调试 | 断点空心、直接跑完 | 配置层 | 是否有-g，program是否匹配 |
这张表我存在笔记里，报错一出来先定位到阶段，再决定去动哪个文件，比凭感觉瞎改快得多。有个细节值得单独说：编译阶段报的No such file or directory有两种含义——文件真的不存在，或者路径字符集对不上导致它「看起来不存在」。区分方法是把那条路径复制到资源管理器地址栏里回车，能打开就是编码问题，打不开就是路径写错了。
最后一条经验是：先跑通最小可复现案例，再回大工程。建一个只有hello.c的空目录，把tasks.json和c_cpp_properties.json从大工程拷过来，能编能调就说明配置没问题，是大工程里某个具体文件或路径的锅；编不过就说明配置文件本身有问题，可以放心地推倒重来。
从那以后我每换一台机器，都强制走一遍三连：where.exe gcc、gcc -v、在终端里手编一个 hello，全过了才去打开 VSCode 写tasks.json。这套流程没有任何技术含量，但它让我再也没在环境问题上熬过夜。希望帮到你。
本文还有配套的精品资源，点击获取
