问题描述：在初学者使用Vscode进行C语言编程时，我们会发现它的环境配置稍微比Python较为复杂，尤其是当我们作为初学者在后续学习中删除文件时不小心将相关文件删除或移动后，往往C/C++环境就随之失效了，本文章旨在提供一种稳定而全面的修复方案以供读者参考学习。

---

摘要：本文章通过采用MSYS2 + MinGW-w64 UCRT64这种稳定的方法来解决Windows系统上旧 MinGW 损坏/被移动后路径失效的问题，主要内容包含故障类型排查思路、相关命令行测试代码、相关具体页面截图，为读者解决相关问题提供参考思路。

---

创作思路：基于一个巧合，本人在用Vscode搭建一个硬件相关的工程时突然发现了之前配置好的C相关配置失效了，于是顺手尝试修复相关配置，通过查找相关资料问题最终解决了这个问题，由于本人觉得这个问题场景对于计算机初学者具有一定的参考意义，于是便打算趁着周六没啥事把解决思路稍微整理一下（顺便锻炼一下语言组织能力哈哈哈哈~）

---

OK，那么回归正题，如果你的Vscode突然发现无法用来编译.c/.cpp文件应该怎么办呢？

首先，我们可以先尝试用以下相关命令行在终端中执行来检测本机上是否有C/C++相关编译器

gcc --version
g++ --version
where gcc

注意：这里的where gcc我们输入的时候可能终端没有反应，不一定代表 gcc 找不到。因为 PowerShell里的where可能不是Windows的where命令（准确来说是cd终端中的查找方式），而是别名。我们可以试试这个命令行：

where.exe gcc
where.exe g++

正常情况下，我们可以看到

这就说明我们的电脑上其实是有相关的环境配置的，下面，我们可以这样来做尝试：

首先，我们先写好一个最简单的C语言程序，保存后命名为test.c文件

#include <stdio.h>

int main() {
    printf("hello C\n");
    return 0;
}

然后我们尝试在终端执行以下相关命令行：（最好分开执行，不要直接复制）

gcc test.c -o test.exe
.\test.exe

这里还有一个值得注意的问题，如果我们是在一个多层目录中进行.c文件测试，我们在终端执行命令来手动进行编译时要保证终端路径要与子目录路径相匹配，不然容易出现这种报错。

test.c: No such file or directory

如果我们想偷懒，可以可以用命令行来确认对应路径呢？当然是没有问题滴~

我们可以尝试用cmd窗口中命令行来尝试查找其相关路径：

dir /s /b test.c

比如说我当时在那个工程文件中是这样来调试的，在执行上面命令行后，我得到以下反馈：

通过查询得知，我这个方式是偏向CMD命令符的写法，PowerShell会把 /s、/b这种 当成奇怪的参数，最终导致报错，我们可以通过采用这行命令来调试，它的意思是从当前目录开始，递归查找名字叫 test.c 的文件，并输出完整路径.

Get-ChildItem -Recurse -Filter test.c | Select-Object -ExpandProperty FullName

到这里，我们已经得到了这个文件的路径。

然后我们通过调整使得子目录路径与PowerShell保持一致：(注:复制时注意空格）

step1:        cd ".\智能小车套件外设控制样例\robot"

step2:        dir test.c

step3:        gcc test.c -o test.exe
step4:        .\test.exe

我在初次调试时得到了这个结果：

这个报错其实已经更加偏向底层，它说明目前gcc已经找到了test.c文件，但它在调用内部编译组件时失败了，可能的原因主要是两个大方向：

1. MinGW 安装不完整 / 被移动过 / 内部路径坏了；
2. 旧版MinGW在中文路径下出问题了，因为我们测试时的路径有包含中文：“智能小车套件外设控制样例”；

第二个原因方便验证一点，于是我们先从第二个开始：

cd E:\
mkdir ctest -Force
cd ctest

@'
#include <stdio.h>

int main() {
    printf("HELLO!\n");
    return 0;
}
'@ | Set-Content -Encoding ASCII test.c

gcc test.c -o test.exe
.\test.exe

在Powershell终端执行这一段命令行，判断预期如下：

1.如果可以正常输出“HELLO”，则说明是中文路径或者项目路径的影响；

2.如果还是出现“CreateProcess: No such file or directory”这类报错，我们可以基本得出结论：MinGW编译器本身出了问题，从而也就引入我们本文的主要内容；

具体步骤

一、关闭Vscode软件

先把 VSCode、PowerShell、CMD 都关掉，避免环境变量缓存。

二、删除旧环境配置

（注：如果读者是新安装可以直接跳过这一步继续看）

点开Win桌面图标，然后搜索“环境...”,点进高级设置

点开后，我们会发现里面有系统变量和用户变量，我们需要检查一下Path，将之前下载的类似：
E:\cenviroment\bin
E:\cenviroment（这是我的初始命名，每个人的可能不一样）
C:\MinGW\bin
D:\MinGW\bin

用户变量界面也是类似的道理，这里点击移除后保存，然后我们需要到对应文件夹中去对相应文件做相关处理，注意，这里避免误删文件，建议我们可以将之前的文件夹改个名字而不是直接删除。

上述步骤完成后，我们可以做下验证，在powershell中运行以下命令行：

where.exe gcc
where.exe g++

理想情况是提示找不到，或者没有输出。
如果还能看到相关路径，说明 Path 里还有残留。

三、安装MSYS2

去 MSYS2 官网（MSYS2官方下载地址）下载安装包，安装路径建议用纯英文路径

再次强调：不要放在中文路径、空格路径里。MSYS2 是一套 Windows 原生开发环境，适合安装和管理 MinGW-w64 GCC。

四、安装GCC工具链

在我们安装好MSYS2后，我们还是按照之前的操作点开Win图标，在搜索框中查找MSYS2

记住我们需要选择UCRT64（UCRT指的是 Windows 的 Universal C Runtime）而不是普通MSYS2，因为MSYS 是工具环境，UCRT64 才是我们写 C/C++ 程序要用的 Windows 编译环境。普通MSYS2更像是给MSYS2自己运行Unix工具用的环境，而UCRT64 是专门给 Windows 编译 C/C++ 程序用的环境，生成的是正常的文件名.exe程序

打开后输入相关命令行：

pacman -Syu

安装过程中都是选择：Y

这是第一步，然后我们可能会被提示需要关闭一下页面，我们先关闭当前窗口，然后再次打开执行上面的那个命令行

pacman -Syu

这是MSYS2在更新自己基础系统组件，以及补齐编译器相关依赖，所以时间上可能有点久直至没有大量更新时，然后我们正式安装gcc工具链，需要再次在这个页面输入命令行：注意，这个安装时间可能有点久

pacman -S --needed mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb make

安装好后我们在检查一下环境配置：

这就说明已经成功安装好了！（注意：第二个那里的ctest文件夹我之前已经建好了，如果没有需要自己先去建）

五、路径配置

现在我们在MSYS2 UCRT64窗口里执行：

which gcc
cygpath -w /ucrt64/bin

它会得到类似这种形式：

/ucrt64/bin/gcc
C:\msys64\ucrt64\bin

其中第二个就是稍后我们要复制到用户变量界面（一般只要改用户变量的，更安全）path路径里的内容，保存好后点击确认，然后再把Vscode重启一下

六、软件测试

注意：测试时需要将文件保存至纯英文路径上，不然容易引发大量奇怪的报错，类似下面这种：

可以参照这种项目结构（规范化）：

E:\cwork
├── c_practice
├── cpp_practice
├── algorithm
├── os_code
└── testcode

小结

注：在软件测试这一部分时，可能还是会些莫名奇妙的报错，就我而言，当时忘记中文路径这一因素，导致调试了比较久，但往往这样的经历才伴随着成长。读者可以根据具体情况自行寻找解决方案，因为每个人的电脑实际情况不同，不可能100%实现复刻（也不应该追求100%复刻），我认为变化恰是计算机的魅力所在，解决问题的过程往往比实现解决问题的效果对个人长期发展更有益，适当的留白才能更好地促使技术成长，希望大家多多探索，多多收获！

本人的第一篇博客，完结撒花啦！🌸