简介：这份PDF教程面向需要在Windows（兼顾Linux）上使用Visual Studio Code编写与调试C、C++程序的开发者，尤其适合刚接触VSCode、对编译与调试配置不熟悉的初学者。内容围绕VSCode安装、C/C++插件获取、MinGW编译调试环境搭建、系统环境变量path配置以及launch.json调试文件修改等关键环节展开，并针对不同版本VSCode与cpptools插件的变化做了标注说明，帮助读者解决配置过程中常见的编译失败、调试无法启动等问题。资源包内共1个PDF文件，大小约852KB，以图文步骤形式呈现，便于按章节对照操作。目前已有5113人学习下载，说明该配置流程具有较高的参考价值。读者可从中获得从零搭建C/C++开发环境的完整思路、调试配置模板以及排错方向，适合作为VSCode入门配置的实操参考。
1. 在 Windows 上把 VS Code 变成 C/C++ 开发环境：为什么你装了插件还是跑不起来
很多人第一次在 VS Code 里写 C 或 C++，卡住的地方不是语法，而是「点运行没反应」「终端一闪而过」「提示找不到 gcc」。VS Code 本身只是个编辑器，它不带编译器，也不自带 C/C++ 的构建链路。你在 VS Code 里配置 C、C++ 环境，本质上是三件事拼起来：装一个真正的编译器（Windows 上通常是 MinGW-w64 里的 gcc/g++）、让 VS Code 的 C/C++ 扩展找到这个编译器、再配一套任务或调试配置把「编译 + 运行」串起来。这套东西在 Windows 上最容易翻车，因为路径、编码、终端类型三个变量互相干扰。这篇面向的是刚上手、想在本机把单个 .c/.cpp 文件跑起来的人，也适合已经能跑但想搞清楚 tasks.json 和 launch.json 到底在干什么的人。Linux 部分会简要带过，因为那边通常一条命令就装好了。
2. 装编译器与扩展：MinGW-w64 怎么选、PATH 怎么配才不玄学
2.1 为什么是 MinGW-w64 而不是别的
Windows 上没有原生的 gcc，你需要一个把 GCC 移植过来的工具链。常见做法是用 MinGW-w64，它同时支持 32 位和 64 位，社区维护活跃。注意区分两个东西：老旧的 MinGW 项目基本停更，MinGW-w64 才是现在该用的。另一个选择是 MSVC（微软自家的编译器），它和 Visual Studio 绑定较深，如果你只是想在 VS Code 里快速跑单文件，MinGW-w64 的配置链路更短、更透明。
选版本时看三个维度：架构（x86_64）、线程模型（posix 或 win32）、异常模型（seh 或 sjlj）。对纯 C/C++ 学习和小项目，选 x86_64 + posix + seh 这一组合最省事。posix 线程模型对后续用 std::thread 更友好，seh 异常模型在 64 位上性能更好。下载下来是一个压缩包，解压到一个没有空格、没有中文的路径，比如C:\mingw64。路径带空格是后面很多玄学问题的根源，别问我是怎么知道的。
2.2 把 bin 目录加进 PATH
解压后，编译器可执行文件在C:\mingw64\bin下，里面有 gcc.exe、g++.exe、gdb.exe。你要把这个 bin 目录加到系统环境变量 PATH 里，否则 VS Code 和终端都找不到它。
操作步骤：Win 键搜索「环境变量」→ 打开「编辑系统环境变量」→「环境变量」→ 在「系统变量」里找到 Path → 编辑 → 新建 → 填入C:\mingw64\bin→ 一路确定。改完必须重开终端和 VS Code，因为 PATH 是进程启动时读取的，已经开着的窗口不会刷新。
验证是否成功，打开一个新的 PowerShell 或 CMD：
gcc --version g++ --version gdb --version三条都能打印出版本信息，说明 PATH 配好了。如果提示「不是内部或外部命令」，九成是路径写错或没重开终端。这里有个细节：如果你之前装过别的编译器，PATH 里可能有多个 gcc，用where gcc可以看实际调用的是哪一个，顺序不对会调用到旧版本。
2.3 VS Code 侧要装哪些扩展
打开 VS Code，扩展面板搜 C/C++，装微软官方的那个（发布者是 Microsoft），它提供智能提示、跳转、调试支持。再装一个 Code Runner 是可选的，它能一键跑当前文件，但它默认的编译命令很粗糙，不适合带多文件或需要特定参数的项目。我的建议是：先用官方 C/C++ 扩展 + 自己写 tasks.json，把链路搞明白，Code Runner 当快捷方式用可以，但别把它当唯一手段。
装完扩展后，VS Code 可能会提示你配置 IntelliSense，先不用管，等我们把编译跑通再回来处理头文件路径。
3. 写第一个程序并配 tasks.json：从「终端一闪而过」到稳定输出
3.1 建工作区与源文件
先建一个专门放代码的文件夹，比如D:\cpp_workspace，用 VS Code 打开这个文件夹（File → Open Folder），而不是单独打开一个文件。打开文件夹后，VS Code 会把它当作工作区，.vscode配置目录就建在这里面，配置只对这个工作区生效，不会污染全局。
新建hello.c：
#include <stdio.h> int main(void) { printf("hello from C\n"); return 0; }再建一个hello.cpp用来对比：
#include <iostream> int main() { std::cout << "hello from C++" << std::endl; return 0; }3.2 tasks.json：告诉 VS Code 怎么编译
按 Ctrl+Shift+P 打开命令面板，输入 Tasks: Configure Task，选「Create tasks.json file from template」，再选 Others。VS Code 会在.vscode下生成 tasks.json。把它改成下面这样，支持编译当前打开的 .c 或 .cpp 文件：
{ "version": "2.0.0", "tasks": [ { "label": "build active file", "type": "shell", "command": "gcc", "args": [ "-g", "-Wall", "-Wextra", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": ["$gcc"], "group": { "kind": "build", "isDefault": true }, "detail": "使用 gcc 编译当前 C 文件" }, { "label": "build active cpp file", "type": "shell", "command": "g++", "args": [ "-g", "-Wall", "-Wextra", "-std=c++17", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": ["$gcc"], "group": "build", "detail": "使用 g++ 编译当前 C++ 文件" } ] }逻辑说明：command指定用哪个编译器，C 用 gcc，C++ 用 g++。args里-g生成调试信息，后面 launch.json 调试时要用；-Wall -Wextra打开常用警告，能提前暴露很多低级错误；${file}是当前文件路径，${fileDirname}是当前文件所在目录，${fileBasenameNoExtension}是不带扩展名的文件名。输出统一放到同目录下的同名 .exe。problemMatcher用$gcc，编译报错会显示在「问题」面板里，点一下能跳到出错行。group里isDefault: true表示按 Ctrl+Shift+B 时默认跑这个任务。
参数怎么改：如果你要链接数学库，在 args 里加-lm；要指定 C 标准，加-std=c11；要开优化，加-O2。注意-o后面的路径用了反斜杠，Windows 下没问题，但如果你把工作区放到 WSL 或 Linux，要改成正斜杠。
3.3 编译并运行
打开 hello.c，按 Ctrl+Shift+B，选择「build active file」。如果没报错，同目录下会出现 hello.exe。在 VS Code 内置终端里运行：
.\hello.exe能打印出 hello from C 就说明编译链路通了。C++ 文件同理，选「build active cpp file」任务。
这里解释一下「终端一闪而过」：如果你直接双击 exe，程序跑完窗口立刻关闭，看起来像没运行。这不是程序的问题，是 Windows 控制台的行为。在 VS Code 终端里运行，或者用调试模式启动，就不会闪。另一个常见现象是中文乱码，原因是源文件编码和终端编码不一致。VS Code 默认用 UTF-8 保存，而 Windows 终端默认可能是 GBK。解决办法有两个：一是把源文件另存为 GBK，二是在终端里执行chcp 65001切到 UTF-8。我一般用后者，因为改文件编码容易在团队协作时出问题。
4. launch.json 调试配置：断点、变量查看与三个必调参数
4.1 生成 launch.json
点左侧「运行和调试」图标，点「创建 launch.json 文件」，选择 C++ (GDB/LLDB)。VS Code 会生成一个模板。把它改成下面这样：
{ "version": "0.2.0", "configurations": [ { "name": "调试当前 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", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "build active file" } ] }逻辑说明：program指向要调试的可执行文件，必须和 tasks.json 里-o的输出路径一致，否则会提示找不到程序。miDebuggerPath指向 gdb.exe 的完整路径，如果你 PATH 配好了，这里也可以只写gdb，但写全路径更稳。preLaunchTask是关键，它让调试前自动先编译，值必须和 tasks.json 里的label完全一致，大小写都不能错，这是最常见的翻车点之一。externalConsole设为 false 表示用 VS Code 内置终端，设为 true 会弹出一个独立控制台窗口，某些需要交互输入的程序用 true 更顺手。
4.2 三个必调参数
第一个是stopAtEntry。设为 true 时程序会在 main 函数第一行停下，适合你想从头单步跟踪；设为 false 则直接运行到你的断点。新手建议先设 true，确认调试器能正常挂上。
第二个是MIMode。用 gdb 就写 gdb，如果你用的是 LLDB 就写 lldb。Windows 上 MinGW-w64 配套的是 gdb，别写错。
第三个是preLaunchTask。前面说了，它决定调试前跑哪个编译任务。如果你有多个任务，比如 C 和 C++ 各一个，那 launch.json 里也要对应建两个 configuration，分别指向不同的 preLaunchTask，否则调 C++ 时可能用了 C 的编译任务，链接阶段报一堆 undefined reference。
4.3 打断点看变量
在代码行号左边点一下会出现红点，那就是断点。按 F5 启动调试，程序会在断点处停下，左侧「变量」面板能看到当前作用域的值，「监视」面板可以手动输入表达式求值。调试控制台里可以输入 gdb 命令，比如p variable打印变量。单步用 F10（跳过函数）和 F11（进入函数），继续用 F5。
如果断点变成灰色空心圆，说明调试器没挂上，通常是 program 路径不对或 preLaunchTask 没跑成功。先看「终端」面板里编译有没有报错，再看「调试控制台」里 gdb 的输出。
5. 避坑与常见问题：编码、路径、多文件和终端选择
5.1 中文乱码
现象：printf 输出的中文在终端里变成乱码。原因：源文件是 UTF-8，Windows 终端默认代码页是 GBK。解决：在终端执行chcp 65001切到 UTF-8，或者在 tasks.json 的 args 里加-fexec-charset=GBK让编译器输出 GBK 编码的字符串。前者改终端，后者改产物，按你的使用场景选。
5.2 路径含空格或中文导致编译失败
现象：报错信息里出现奇怪的路径截断，或者提示找不到文件。原因：MinGW 工具链对含空格、中文的路径支持不好，尤其是-o输出路径。解决：把工作区和 MinGW 都放在纯英文、无空格的路径下，比如D:\cpp_workspace和C:\mingw64。这是血泪经验，别图省事放在「我的文档」里。
5.3 多文件项目编译不过
现象：两个 .c 文件互相调用，单独编译每个都过，合起来报 undefined reference。原因：tasks.json 里只编译了${file}当前文件，没有把其他源文件一起编。解决：把 args 里的${file}换成${fileDirname}\\*.c，或者显式列出所有源文件。更规范的做法是学 Makefile 或 CMake，但对小项目，通配符够用。注意通配符在 Windows 的 shell 里行为可能和预期不同，稳妥起见显式列文件名。
5.4 调试时提示「无法启动程序」
现象：按 F5 后弹窗说找不到 exe。原因：program 路径和实际输出路径不一致，或者 preLaunchTask 没执行成功。解决：先手动按 Ctrl+Shift+B 编译一次，确认 exe 生成在哪个目录，再把 program 改成对应路径。同时检查 preLaunchTask 的字符串和 tasks.json 的 label 是否一字不差。
5.5 终端类型选错
现象：在 PowerShell 里能跑的命令，在 VS Code 默认终端里报错。原因：VS Code 默认终端可能是 PowerShell，而某些命令语法和 CMD 不同。解决：在设置里搜 terminal integrated default profile windows，选 Command Prompt 或 PowerShell 按你的习惯固定下来。我一般用 PowerShell，但编译命令尽量用不依赖 shell 特性的写法，减少环境差异。
6. Linux 简要配置与进阶：从单文件到 CMake 的过渡技巧
Linux 上事情简单很多。以常见发行版为例，装编译器：
sudo apt update sudo apt install build-essential gdbbuild-essential会把 gcc、g++、make 一起装上。VS Code 侧装同样的 C/C++ 扩展，tasks.json 里把 command 写成 gcc/g++，路径用正斜杠，输出文件不加 .exe 后缀即可。launch.json 里 miDebuggerPath 写/usr/bin/gdb，program 写${fileDirname}/${fileBasenameNoExtension}。其余逻辑和 Windows 一致。
当你从单文件过渡到多文件项目，手写 tasks.json 会越来越吃力。这时候该上 CMake。一个最小 CMakeLists.txt：
cmake_minimum_required(VERSION 3.10) project(demo C CXX) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 17) add_executable(demo main.c util.c)然后在 VS Code 里装 CMake Tools 扩展，它会自动读取 CMakeLists.txt 并生成构建任务，调试配置也能自动推导。这一步的价值在于：你不再需要为每个新文件改 tasks.json，增删源文件只改 CMakeLists 一行。我自己的习惯是，单文件练习用 tasks.json 快速验证，一旦超过三个源文件就立刻切 CMake，否则后面链接错误会多到让你怀疑人生。
最后一个具体技巧：把常用的编译参数抽成变量。tasks.json 支持${config:xxx}引用 VS Code 设置，你可以在 settings.json 里定义"myCppFlags": ["-Wall", "-Wextra", "-O2"]，然后在 args 里用${config:myCppFlags}展开。这样换项目时只改一处设置，不用每个 tasks.json 都翻一遍。这个习惯帮我省下了大量重复劳动，希望帮到你。
本文还有配套的精品资源，点击获取
