企业官网建设流程全解析

看到网上铺天盖地的“VS Code 配置 C 语言”教程，许多人的结局总是出奇一致：跟着博主装完扩展，兴冲冲按下运行，结果终端跳出一行gcc 不是内部或外部命令，然后开始漫长的百度、试错、卸载重来。这个场景我见了太多次。其实用 Visual Studio Code 写 C、C++ 程序的逻辑并不复杂，你只需要搞明白三件事：编译器装在哪、VS Code 怎么调用它、调试器怎么接进来。这篇内容就是把你需要经历的完整流程、每一步背后的原因、以及我实际踩过的坑一次讲透，让刚接触编程的同学能顺着这条链路直接跑通。

1. 为什么我建议用 VS Code 写 C/C++：并非因为它最“傻瓜”

很多同学下意识把 VS Code 当成“C 语言专用软件”，装了发现它连编译按钮都没有，于是觉得这是个假编辑器。这个误解的根源在于：VS Code 不是 IDE，而是一个编辑器。

1.1 VS Code 和 Visual Studio 的真实区别

Visual Studio（简称 VS）是微软出品的重量级 IDE，安装完自带编译器、调试器、项目模板、图形化界面设计器，Windows 平台上写 C/C++ 是“开箱即用”的。它确实强大，但换来的是巨大的安装体积、较慢的启动速度，以及被项目结构绑定后的不灵活。很多竞赛选手和工程老手反而嫌它笨重。

VS Code 的本质是“可扩展的编辑器”，它自身只做文本编辑，代码高亮、补全、编译、调试全部依赖扩展和外部工具链。换句话说，VS Code 给了你一个干净的操作台，但是炒菜的锅和灶要你自己搬过来。这就是为什么很多人装完 VS Code 后一脸懵：没编译器、没调试器、连“如何运行一个程序”都找不到入口。

两者的选择逻辑很简单：如果你主要做 Windows 桌面端大型项目，或者被某些课程教材要求使用 Visual Studio，那直接用 VS；如果你想写点算法题、学习 C/C++ 语法、或者希望以后在 Windows/Linux/macOS 上用同一套工具，那 VS Code 是更清爽的选择。

1.2 什么样的人适合用 VS Code 写 C/C++

以我的经验，下面这几类人非常适合在 VS Code 里折腾 C/C++：

• 刚学编程的大学生，主要写几百行的练习程序，不需要复杂的项目向导。
• 需要频繁切换语言的人。VS Code 一个窗口通吃 Python、JavaScript、C/C++，不用来回换 IDE。
• 想练 “命令行编译 + 手动排错” 基本功的人。这听着痛苦，但真的能帮你理解编译链接的原理。
• 以后打算做后端、嵌入式或者开源项目的人，VS Code + GCC 这套组合在跨平台开发中非常常见。

反过来，如果你发现自己只想双击一个图标、点一下绿色三角就能跑程序，不想关心 PATH、编译器、json 配置这些东西，那我建议你老老实实去用 Dev-C++ 或者 Code::Blocks，它们不丢人，只是工具定位不一样。用 VS Code 需要一点折腾精神，这也是为什么网上教程满天飞，却依然有一堆人配置失败的原因。

1.3 “编辑器 + 编译器 + 调试器”这套组合逻辑

在动手配置之前，先建立一个整体认知。VS Code 写 C/C++ 程序，完整链条是：

1. 你用编辑器（VS Code）写源代码。
2. 用编译器（GCC/MinGW-w64）把.c或.cpp源码翻译成可执行文件.exe。
3. 用调试器（GDB）帮你逐行检查程序，看变量值怎么变化。
4. VS Code 负责把 2 和 3 的操作封装成按钮和快捷键，比如 F5 一键调试。

这个链条中，VS Code 只是“操作台”，真正干活的编译器和调试器必须单独安装。我会用“厨师、炉灶、温度计”来比喻：VS Code 是厨师，负责切菜摆盘；MinGW-w64 是炉灶，负责把生米煮成熟饭；GDB 是温度计，用来判断火候是否到位。少任何一个环节，菜都出不来。理解了这条链路，后面所有配置你都看得懂，而不是机械地照抄。

2. 装编译器才是最劝退的一步：MinGW-w64 与新手的第一次交锋

坦白讲，VS Code 的安装本身没有难度，难点几乎全在编译器安装和环境变量配置上。这一节我会从原理到操作展开，把它彻底掰开揉碎。

2.1 为什么 C/C++ 编程必须安装独立的编译器

CPU 只认识机器指令（0 和 1），不认识printf("hello");。编译器负责把人类可读的 C/C++ 源码，翻译成 CPU 能执行的机器码，生成一个可执行文件。VS Code 是文本编辑器，它不负责翻译，所以你必须自己安装一个编译器。

Windows 上常见的 C/C++ 编译器有两大流派：

• MSVC（Microsoft Visual C++），来自 Visual Studio，用cl.exe命令。它和 Windows 系统集成度高，但只能在 Windows 上用，配置相对复杂。
• GCC（GNU Compiler Collection），跨平台开源编译器，在 Windows 上的移植版就是 MinGW-w64，用gcc.exe（编译 C）和g++.exe（编译 C++）命令。

绝大多数 VS Code 教程选用的是 MinGW-w64，因为它开源、轻量、和 VS Code 兼容性好，而且gdb.exe调试器也一样齐全。

有个容易搞混淆的东西我必须提一下：你在网上会看到很多人遇到Microsoft Visual C++ Redistributable is not installed这种报错，那是程序运行时需要的 VC++ 运行库，不是编译器，和 VS Code 里能不能编译 C 语言没有直接关系。这个我后面会在避坑章节详细讲。

2.2 MinGW-w64 的下载与安装手法

我自己最推荐的方式是使用 MSYS2 安装 MinGW-w64，因为它带了一个包管理器，以后更新工具链、安装额外组件都很方便。不过 MSYS2 本身对新手有点抽象，所以这里给出两条路线，凭个人偏好选。

路线一：使用 MSYS2 安装

1. 去 MSYS2 官网下载安装包，按提示安装到默认目录，例如C:\msys64。
2. 安装完成后打开 “MSYS2 UCRT64” 终端，执行：

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

   等待下载安装完成。
3. 关闭 MSYS2 终端后，找到C:\msys64\ucrt64\bin目录，里面应该就有gcc.exe、g++.exe、gdb.exe了。

路线二：直接下载免安装压缩包

如果你不想引入 MSYS2 这一层，也可以到 WinLibs 这类网站下载 GCC 的 Windows 编译版压缩包，解压到你想要的位置，比如C:\mingw64。解压完成后，找到C:\mingw64\bin，里面同样是那三个关键文件。

不管走哪条路，有两个原则别违反：

• 安装或解压路径尽量不要有中文、不要有空格。C:\mingw64最省心，D:\Program Files\mingw64这种路径可能在部分工具链或较老的环境里出幺蛾子。
• 尽量用较新的版本，不要为了“稳定”去用七八年前的远古 MinGW。老版本对 C++17/C++20 新特性的支持很差，而且更容易出兼容问题。

2.3 环境变量 PATH 到底改的是什么

“环境变量”这四个字听起来高大上，说白了就是给操作系统的一张“查人表”。你在终端里敲gcc，系统就得去 PATH 指定的许多目录里逐个找有没有叫gcc.exe的文件。如果 PATH 里没有C:\mingw64\bin，系统就会告诉你说gcc不是内部或外部命令。

配置步骤如下：

1. 右键“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。
2. 在“用户变量”列表里找到Path（如果没有就新建一个），双击编辑。
3. 点击“新建”，把编译器 bin 目录的完整路径填进去。以 MSYS2 为例是C:\msys64\ucrt64\bin；以解压版为例是C:\mingw64\bin。
4. 确定保存。

这里建议修改“用户变量”里的 PATH，而不是“系统变量”。用户变量只对当前用户生效，更安全；系统变量全局生效，改错了可能影响整个系统，没必要冒这个险。改完之后，所有已经打开的命令行窗口都得关掉重新开，因为终端启动时会读取一次环境变量，不会实时刷新。

2.4 验证编译器是否安装成功的方法

配置完成后，打开一个全新的 CMD 窗口（按 Win+R 输入cmd）或者 VS Code 终端，依次执行：

gcc -v g++ -v gdb -v

如果输出了一长串版本信息，末尾能看到gcc version xxx之类的内容，说明编译器已经能正常被系统找到。我见过很多人在这里出问题：gcc --version显示是个未知命令，结果发现他们是在配置完环境变量之前的旧终端里测试的，自然不行。

这一步有一个小技巧：不要只看能不能找到 gcc，还要注意g++和gdb是否都能找到。因为 C++ 程序的编译要用到g++，调试器要用到gdb，三者缺一不可。

3. 扩展安装和配置文件：真正决定“能不能跑”的细节

编译器就绪之后，回到 VS Code，还需要装扩展。扩展装不对、配置不合适，依然会出现“代码没问题，但运行不了”的状况。

3.1 必装扩展：C/C++ 与 Code Runner 的分工差异

打开 VS Code 扩展商店（快捷键Ctrl+Shift+X），搜索并安装这两个扩展：

• C/C++：由微软官方出品，包名为ms-vscode.cpptools。它提供代码提示、跳转定义、符号搜索、调试支持。注意，它本身不编译程序，但它是让 F5 调试工作起来的关键。
• Code Runner：包名为formulahendry.code-runner。它提供“一键运行”功能，在代码文件右上角会出现一个播放按钮，快捷键是Ctrl+Alt+N。它负责快速编译并运行当前文件，适合写练习和测试时使用。

如果你打开 VS Code 发现是英文界面，可以在扩展商店搜索Chinese (Simplified) Language Pack并安装，重启后就是中文界面。这是很多新手下载后做的第一件事，其实无所谓，英文界面用多了也顺手。

关键点在于，C/C++ 扩展和 Code Runner 的职责不同。C/C++ 扩展管“开发体验和调试”，Code Runner 管“快速跑当前文件”。很多人以为装了 C/C++ 扩展就等于能编译了，结果发现右键只有“Run Code”能用，F5 却报错，就是因为两者混为一谈了。

3.2 最简单的运行方式：右键 Run Code

安装 Code Runner 之后，在源码文件里按Ctrl+Alt+N，或者右键选择“Run Code”，程序就编译并运行了。默认情况下，它会在“输出”面板里显示结果。

但这个默认配置有几个隐患：第一，程序里的scanf或cin需要输入内容，默认的输出面板不支持交互式输入，程序会卡住或什么也接收不到；第二，运行结束后窗口直接关闭，你根本看不到结果；第三，它不区分 C 还是 C++ 编译规则，偶尔会选错编译器。

所以我强烈建议在 VS Code 设置里做一件事：

1. 按Ctrl+,打开设置。
2. 搜索code-runner.runInTerminal，勾选上。
3. 这样 Code Runner 会在集成终端里运行程序，支持键盘输入，程序运行结束后也会保留现场。

如果有乱码问题，还可以加一段配置。打开settings.json（设置界面右上角箭头），粘贴或修改成类似内容：

{ "code-runner.runInTerminal": true, "code-runner.executorMap": { "c": "cd $dir && gcc $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt", "cpp": "cd $dir && g++ $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt" }, "code-runner.ignoreSelection": true }

这段配置的意思是：对.c文件用gcc编译，对.cpp文件用g++编译，编译产物和源码同名（没有后缀），然后在当前目录直接运行。其中$dir是源文件所在目录，$fileName是当前文件名。如果你不希望源码目录里堆满 exe，也可以改成指定输出到单独目录，这里先保持最简单。

3.3 正确理解 tasks.json 和 launch.json 的关系

当你要用 F5 调试时，VS Code 会依赖两个配置文件，都在项目根目录的.vscode文件夹里：

• tasks.json：定义“编译任务”。它告诉 VS Code 用什么命令把源代码编译成可执行文件。
• launch.json：定义“调试配置”。它告诉 VS Code 调试器要加载哪个可执行文件，以及如何连接调试器。

打个比方：tasks.json 负责“做饭”，launch.json 负责“试菜”。你 F5 调试时，VS Code 会先执行 tasks.json 里的编译命令生成 exe，然后让调试器去启动这个 exe。

VS Code 不会自动为你生成 C/C++ 的 tasks 和 launch 配置，但会在你第一次按 F5 时弹出询问。理解这两个文件的职责，你才能从容应对各种教程里给出的 JSON 片段，否则就是“复制粘贴，报错不知所措”。

3.4 尽量不要直接复制网上“老教程”的配置片段

VS Code 的更新速度很快。网上很多两三年前的教程里，还给launch.json配"externalConsole": true时夹带一些老旧的字段名，比如"terminal.integrated.shell.windows"已经被新版本标为废弃。如果你复制到的配置包含废弃字段，轻则配置不生效，重则在设置页面直接报黄条警告。

我的建议是：把配置文件的字段当成“命令的参数”来理解，而不是背 JSON。只要能看懂每个字段的作用，你就不怕版本更新。遇到报错，优先去 VS Code 官方文档或 C/C++ 扩展官方的说明里查字段，而不是随便搜一篇教程就往上套。类似的坑还包括：字段名少写一个字母、路径末尾多了反斜杠、JSON 里多了尾逗号——这些都会让配置文件直接罢工。

4. 从 Hello World 到单文件调试：完整跑通一条链路

讲了这么多背景和原理，现在动手。我会带着你把一个 C 语言程序从创建文件到 F5 调试完整跑通。

4.1 新建一个 C 文件，第一次运行

在 VS Code 中新建一个文件夹，例如D:\c-practice，然后用 VS Code 打开它，新建一个文件hello.c，写入：

#include <stdio.h> int main() { printf("Hello, World!\n"); return 0; }

按Ctrl+Alt+N，如果配置正确，终端里会出现编译命令并输出：

Hello, World!

这里有个容易让新手困惑的点：Code Runner 默认调用的确实是 GCC，但它在底层会使用一个“默认编译器”判断逻辑。如果你同时装了多个编译器，可能不是你想要的那个。所以下面的 tasks.json 配置，才是你把编译行为真正攥在自己手里的方式。

4.2 配置 tasks.json：把编译命令攥在自己手里

在项目根目录新建.vscode文件夹，然后新建.vscode/tasks.json，内容如下：

{ "version": "2.0.0", "tasks": [ { "label": "C/C++: gcc 编译当前文件", "type": "process", "command": "gcc", "args": [ "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [] } ] }

关键字段解释：

• command：指定用哪个程序编译，这里是gcc。如果你要编译 C++，可以改成g++，或在命令里写g++。
• args：编译参数。-g表示生成调试信息，没有它，调试器看到的变量名和源代码行号都是空的。${file}是当前文件路径，-o指定输出文件。
• group：表示这是一个构建任务，isDefault为 true，意味着按Ctrl+Shift+B会直接执行它。

保存后按Ctrl+Shift+B，如果生成一个hello.exe文件，编译就成功了。这时候再打开集成终端，手动输入.\hello.exe也能看到程序输出。

4.3 配置 launch.json：让 F5 能真正调试

接下来配置调试。在.vscode文件夹里新建launch.json：

{ "version": "0.2.0", "configurations": [ { "name": "C/C++ 调试", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:/mingw64/bin/gdb.exe", "preLaunchTask": "C/C++: gcc 编译当前文件" } ] }

注意几个容易出错的地方：

• program必须指向你 expected 的 exe 路径，要和 tasks.json 的输出文件名一致。
• miDebuggerPath必须写成你的 gdb.exe 的完整路径。如果用的是 MSYS2 环境，路径是C:/msys64/ucrt64/bin/gdb.exe。很多人在这一步填错了路径，导致 F5 报错说找不到调试器。
• preLaunchTask要和 tasks.json 里的label完全一致，否则 VS Code 会提示找不到前置任务，无法自动编译。
• externalConsole设为false，在 VS Code 集成终端里调试，输出与交互都在编辑器下方；设为true则会弹出一个独立命令行窗口，操作起来反而麻烦。

现在，在hello.c里第 5 行（printf那一行）打一个断点，按 F5，你会发现程序停在断点上。左侧面板能看到局部变量、监视表达式和调用堆栈。

4.4 调试界面的正确打开方式

调试启动后，你会看到顶部出现一排调试控制按钮：

• 继续（F5）：直接运行到下一个断点或程序结束。
• 单步跳过（F10）：执行当前行，但不进入函数内部。
• 单步进入（F11）：执行当前行，并进入函数内部。
• 单步跳出（Shift+F11）：执行完当前函数剩余部分，返回到调用处。
• 重启与停止：重新开始调试或结束调试。

初学调试时，最好的练手方式是在自己写的一个函数里打断点，观察参数怎么传入、局部变量怎么变化。比如写一个求阶乘的函数，在result *= i那行打断点，用 F10 单步走，你会看到变量result一步步变大。这种“肉眼观察程序执行轨迹”的体验，对于理解循环和递归的帮助，比任何教程都管用。

5. 多文件工程与编译优化：从“能跑”到“好用”

单文件练习没问题之后，你会开始接触多文件结构、算法优化、甚至 CMake。这一节说说怎么往上走。

5.1 多个 .c/.cpp 文件怎么编译

Code Runner 默认只编译当前文件，当你写了一个main.c，里面调用helper.c中的函数时，直接用 Code Runner 大概率会报链接错误，比如undefined reference to xxx。原因很简单：编译器只单独编译了一个源文件，链接器自然找不到另一个文件的函数实现。

解决方式有两种。

方式一：手动在终端编译

gcc -g main.c helper.c -o myprogram.exe

这里把参与编译的所有.c文件都列在命令后面，GCC 会分别编译它们，然后链接成一个可执行文件。C++ 同理，用g++ main.cpp helper.cpp -o myprogram.exe。

方式二：修改 tasks.json

把args里的${file}改成你希望参与编译的文件列表，比如：

"args": [ "-g", "main.c", "helper.c", "-o", "main.exe" ]

但这种方式每加一个源文件就要改一次配置，文件一多就烦了。到这一步，你就该考虑 CMake 了。

5.2 更规范的工程方式：引入 CMake

现代的 C/C++ 项目大多用 CMake 管理构建过程，VS Code 配合 CMake Tools 扩展，体验非常接近 IDE。在项目根目录创建一个CMakeLists.txt：

cmake_minimum_required(VERSION 3.20) project(MyProject) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 17) add_executable(my_program main.cpp helper.cpp)

然后在 VS Code 里安装CMake Tools扩展，按Ctrl+Shift+P输入 “CMake: Configure”，选择编译器路径，再按底部的 Build 按钮。CMake 会自动处理源文件列表、编译参数和生成任务，不用再手动维护 tasks.json 里那一长串参数。

很多同学觉得 CMake 是“以后工作了才需要”的东西，其实不然。当你开始写三个以上源文件的练习项目时，CMake 带来的收益就立刻体现出来了。早一点接触，后面学 OpenGL、写小游戏、参与开源项目都能无缝衔接。

5.3 编译参数一栏：-g 调试、-O2 优化、-Wall 告警

编译参数里，最常用的三个是：

• -g：生成调试信息。没有它，GDB 无法把机器指令和源代码行号对应起来，调试时看到的是乱码或十六进制地址。
• -O2：开启优化。编译器会在编译阶段对代码做指令级优化，生成的程序跑得更快。代价是编译时间变长，调试体验变差（变量可能被优化没了）。
• -Wall：显示所有警告。程序员最好的朋友。

举个例子，判断质数的循环里，如果for (int i = 2; i * i <= n; i++)，-O2开启后编译器可能会做一些循环展开之类的优化，让大数测试的速度明显提升。但你在调试阶段千万别开-O2，否则变量被优化掉，断点跳来跳去，心态直接崩掉。所以我的习惯是：调试用-g -Wall，发布和跑性能测试时再加-O2。

5.4 顺手谈谈代码风格和“不要急着用 IDE 帮你写代码”

这里我想多说一句个人经验。网上总有人问“字符串逆序输出怎么做”“冒泡排序怎么写”“指针怎么用”，然后拿着代码块就开始背。工具链配好之后，技术债才真正开始：如果你总是依赖代码自动补全、一键生成代码块，语法结构永远是别人的，不是你的。

我建议初学阶段关掉 IntelliSense 的“快速建议”功能，至少前几周手敲所有代码。敲错了，编译器把错误指出来，你再去读错误信息，这个循环是成长最快的阶段。VS Code 的 C/C++ 扩展补全很强大，但它应该是你的加速器，不是你的拐杖。

6. 配置过程中最容易踩的坑：按链路排查而不是乱试

很多人的配置问题不是“不懂怎么配置”，而是遇到错误后靠碰运气修。这一节我把最常见的四类问题，按照“为什么会出现”和“完整排查链路”串起来讲。

6.1 场景一：gcc 不是内部或外部命令

这个报错出现的原因只有一个：系统在 PATH 里没找到gcc.exe。但导致这个结果的可能性有好几种，按顺序排查：

第一步，打开文件资源管理器，到你的 MinGW 安装目录下的bin文件夹，确认gcc.exe真的存在。不存在？说明安装过程有问题，回去重装。

第二步，在 CMD 里输入echo %PATH%，看看你的 PATH 变量里有没有刚才添加的路径。没有？说明环境变量根本没保存成功，或者保存错了地方。

第三步，如果有路径但对不上，比如路径里有空格或者中文字符，建议换到C:\mingw64之类的位置，重新添加。

第四步，如果你是先打开终端，再去改环境变量的，那么终端不会自动刷新。把终端、VS Code 全部关掉重开，再来一遍gcc -v。

第五步，如果你的 VS Code 是通过桌面快捷方式启动的，有时候它继承的环境变量还是旧的，可以从“开始菜单”重新打开一次。

这里最常见的坑是：在系统属性里改了 PATH，但忘了点“确定”，直接关窗口，等于白改。别笑，这真的是高频操作失误。

6.2 场景二：乱码问题，中文全部变成一团糟

运行程序，printf("你好")输出变成浣犲ソ或??，这是编码不一致问题。MinGW 编译器默认把源文件里的中文字符串以 UTF-8 处理，而 Windows 的 CMD 终端默认代码页是 GBK（936），两边对不上，终端就把 UTF-8 字节解码成了 GBK 显示。

解决办法有三个：

1. 在代码开头加入system("chcp 65001");，动态把终端代码页切换成 UTF-8。缺点是代码会依赖 Windows API，换个平台就不通用。
2. 编译时加参数指定执行字符集：

   gcc -fexec-charset=UTF-8 hello.c -o hello.exe

   或者在 tasks.json 的args里加上"-fexec-charset=UTF-8"。这样程序输出的字符串在背后转成 UTF-8 后，配合 VS Code 终端默认的 UTF-8 编码，就不会乱码了。
3. 更一劳永逸的做法：直接把 VS Code 默认文件编码设置为 UTF-8，并且把终端代码页也改为 UTF-8 风格。在settings.json里加"files.encoding": "utf8"，然后确保终端是全新的。

我给初学者的建议是直接方案二，虽然每次都要在任务里塞一个参数，但不会影响代码可移植性。

6.3 场景三：系统报错需要 Microsoft Visual C++ 运行库

打开某个软件时，遇到Microsoft Visual C++ Redistributable Package (x64) is not installed，这不是 VS Code 配置的问题，也不是 GCC 的问题。它说明那个软件依赖的是 MSVC 运行时库，和 MinGW-w64 编译出的程序没有任何关系。

解决办法是去微软官网下载并安装对应的VC_redist.x64.exe/VC_redist.x86.exe运行库，安装后重启电脑或相关软件。如果你电脑上同时装有 Visual Studio、各种游戏平台、国产软件，这些东西通常已经自带 VC++ 运行库了，缺少哪个装哪个就行。

这个报错和“VS Code 无法编译 C 语言”是完全两码事。很多新手看到Microsoft Visual C++几个字就慌了，以为要装一个巨大的 Visual Studio，其实只是一个小运行库安装包。

6.4 场景四：PowerShell 禁止执行脚本

还有一种报错和 C/C++ 无关但同样高频出现，尤其是在 npm 相关命令里：

无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本

这是 PowerShell 执行策略的限制。VS Code 的集成终端默认可能是 PowerShell，而你的系统执行策略是 Restricted，于是所有.ps1脚本都无法运行。解决办法有两种：

1. 按下Win+X，选择“Windows PowerShell (管理员)”，执行：

   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

   RemoteSigned表示本地写的脚本可以运行，从网上下载的未签名脚本仍然禁止，相对安全。
2. 如果只是为了写 C/C++，更简单的办法是：按Ctrl+Shift+P，输入 “Terminal: Select Default Profile”，把默认终端改成 Command Prompt（cmd），或者改用 Git Bash。CMD 没有执行策略这个概念，最适合新手直接跑gcc。

这个问题虽然不直接影响 GCC，但它总会在你配置环境时突然冒出来，所以单独提一嘴，省得你排查半天。

最后再分享两个我自己一直保持的习惯：第一，每次新建一个 C/C++ 小项目，就把一套能用的.vscode文件夹复制过去，tasks.json 和 launch.json 从老项目里拿，配置稳定且不用从零写；第二，不要追求“最全”配置，等你真的遇到需求再往配置里加内容，不然你会被一堆不知道干什么的 JSON 字段搞晕。VS Code 的配置自由度高是它的优点，但也要求你按需使用，学会做减法，工具才能服务于人而不是反过来折腾你。