简介：面向Windows系统下希望用VSCode编写C/C++的初学者与自学者，这份课程资源围绕开发环境搭建展开，重点解决编辑器安装、编译器配置、插件启用及编译调试中的常见障碍，帮助读者建立可复用的本地开发流程。压缩包内仅含1个DOCX文件，大小约7.46MB，以图文步骤串联VSCode下载安装、中文语言包、MinGW-w64编译器、系统环境变量、C/C++插件以及tasks.json、c_cpp_properties.json等配置环节，并提示路径含中文、调试报错等易错点。已有1486人学习，适合需要按图操作、少走弯路地完成从代码编写到运行调试全流程的读者参考；也可作为课程实验、课程设计或自学练习前的环境准备清单，便于快速核对每一步配置是否到位。对不熟悉命令行与环境变量配置的读者，文档中的操作顺序和易错提示能降低反复试错成本，也可供机房统一部署或同学间互助排查时参考。

1. 劝退之后再装：Windows 上给 VSCode 搭 C/C++ 开发环境到底卡在哪

「装个 VSCode 写 C++，怎么比写代码还累」——这话我在不同机器上听过太多次。Windows 上给 VSCode 搭 C/C++ 开发环境，骨架其实只有三块：编辑器本体、一个 MinGW 编译器、.vscode下的两份 JSON 配置。真正让人翻车的从来不是这三块本身，而是和代码无关的细节：解压出来的目录多套了一层、Path 加成了C:\mingw64而不是C:\mingw64\bin、项目文件夹建在带中文的用户目录下，编译能过、一按 F5 就冒出一串看不懂的报错。

这套组合最适合已经能自己装软件、看得懂路径和命令行的开发者；如果你刚接触编程，先用装完就能直接运行的集成 IDE 把语法练熟，省下来的时间比折腾环境值钱。下面按我实际装机的顺序走一遍，Windows 10 和 11 通用，走完能编译、能调试、能跑多文件项目。

2. VSCode 装 Stable 版与中文语言包：装完先确认这三件事

先把编辑器落地。这一步看着最没技术含量，但后面几个玄学问题（右键没有「通过 Code 打开」、终端里敲code不认、插件装完还是英文界面）基本都出在这一章。

2.1 下载页选哪个包：Stable、User 还是 System

打开官方下载页，页面上会给几个入口，选错了不影响能不能用，只影响后面要不要重装：

架构拿不准就在「设置 → 系统 → 系统信息」里看一眼「系统类型」，写 x64 就下 x64。下错架构的典型表现是装完能打开，但插件市场里搜不到 C/C++ 扩展，或者装上了加载失败。

安装路径那一页，原文说放哪都无所谓，我的习惯是保留默认或者换到D:\Programs\VSCode这种纯英文、不带空格的路径。倒不是 VSCode 本身怕空格，而是后面tasks.json里写编译器绝对路径时，带空格的路径要额外加引号，新手很容易漏。

2.2 安装向导里那页「附加任务」，全都勾上

一路下一步，到「选择附加任务」那一页别急着点。这一页的勾选项决定了你后面用起来顺不顺手：

• 将「通过 Code 打开」操作添加到 Windows 资源管理器目录上下文菜单：勾上之后，在任意文件夹右键就能直接用 VSCode 打开，比每次都「文件 → 打开文件夹」快得多。
• 将「通过 Code 打开」操作添加到 Windows 资源管理器文件上下文菜单：单文件右键打开，看零散代码片段时有用。
• 将 Code 注册为受支持的文件类型的编辑器：.c、.cpp、.h双击默认用 VSCode 打开。
• 添加到 PATH：这一项最关键，勾上之后终端里才能敲code .直接拉起当前目录。没勾的话后面得手动补 PATH，又是一轮折腾。

装完第一次启动，界面是英文的，这很正常——语言包是扩展，不是内置的。

2.3 中文语言包：装完必须重启，不是刷新

按Ctrl + Shift + X打开扩展面板，搜索Chinese，排在最前面的那个简体中文语言包，点安装。装完之后右下角会弹一个提示框，问你要不要 Change Language and Restart，点它。

如果手快点掉了那个提示，也不用重装，用命令面板补一刀：

1. Ctrl + Shift + P打开命令面板；
2. 输入Configure Display Language；
3. 选zh-cn，编辑器会提示重启，重启后就是中文界面。

提示：装完语言包没重启、只在扩展面板里看到「已安装」，界面是不会变的。这一步踩过的人不少，以为是语言包不兼容。

2.4 先建工作区文件夹，路径里不能有中文

这一步原文放在写代码之前，我觉得应该提前到装完编辑器就做，因为它决定了后面所有配置文件放哪。

在磁盘上建一个专门放练习代码的目录，比如C:\code\test_vscode。有两条硬要求：

第一，路径里不能有中文。C:\Users\张三\Desktop\test_vscode这种路径，编译阶段可能勉强能过，调试阶段经常给你来个莫名其妙的报错，报错信息里中文部分还会显示成方块，排查起来像开盲盒。第二，不要放在需要管理员权限才能写的目录，比如C:\Program Files下面，否则 gcc 生成.exe时会因为没写权限而失败，报错还是一堆英文。

建好之后，VSCode 里「文件 → 打开文件夹」，选中它。之后所有.c、.cpp源文件、.vscode配置目录、编译出来的.exe，都在这一个文件夹里，管理起来清爽。

这份 c++ windows 课程资源的配置思路就是按这个顺序走的：编辑器、语言包、工作区先定死，再往里塞编译器，顺序反过来会多绕很多路。

3. MinGW-w64 解压式安装：C:\mingw64 与 PATH 的两处硬要求

VSCode 再能打也只是编辑器，它没有编译器。写完的.c文件它认识语法、能高亮、能补全，但点不了「运行」。要在 Windows 上把 C/C++ 真正跑起来，得给它配一个 gcc。MinGW-w64 就是把 gcc 移植到 Windows 的一套工具链，包含gcc.exe、g++.exe、gdb.exe、mingw32-make.exe，够用了。

3.1 下载页别急着点最上面那个按钮

MinGW-w64 的下载页结构有点劝退，一进去是一堆按版本号排列的目录，页面上最显眼的下载按钮往往不是你要的东西。正确路径是进到mingw-builds那个目录，往下翻，找形如x86_64-8.1.0-release-posix-seh-rt_v6-rev0这样的压缩包。

文件名里三个关键词得看懂，选错了后面会出真问题：

那个8.1.0是 gcc 版本号，不同时间点页面上挂的版本会变，不用纠结具体数字。但线程模型和异常模型这两项，选成 win32 或者 sjlj，后面写 C++11 的线程代码会直接编译不过，报错还特别难懂。

下载得到的是一个.7z压缩包，用 7-Zip 或者 Bandizip 解压。Windows 自带的解压对 7z 支持不好，右键「全部解压缩」有时候会失败。

3.2 解压层级要确认：bin 必须直接挂在 mingw64 下面

解压出来的顶层目录名一般就叫mingw64，里面应该有bin、include、lib、x86_64-w64-mingw32这几个文件夹。把这个mingw64整个目录挪到C:\mingw64，最终C:\mingw64\bin\gcc.exe这个路径必须真实存在。

这里最容易翻车的是多套一层。有些压缩包解压出来是mingw64\mingw64\bin，如果你直接把外层目录改名成C:\mingw64，那实际路径就变成了C:\mingw64\mingw64\bin\gcc.exe，后面 PATH 怎么配都找不到 gcc。解压完先点进去看一眼，确认bin就在第一层。

路径也别带空格和中文。C:\Program Files\mingw64这种，tasks.json里写命令行时要加引号转义，能避开就避开。

3.3 系统变量 Path 追加 C:\mingw64\bin

按Win + S搜「环境变量」，打开「编辑系统环境变量」→「环境变量」，在下半部分的「系统变量」里找到Path，双击打开，点「新建」，填：

C:\mingw64\bin

然后连续点三次「确定」逐层退出。三次确定不是走形式，只点一次关掉窗口的话，改动不会写进注册表，等于白配。

几个细节值得单独说：

• 加的是bin目录，不是C:\mingw64。加错了的表现是终端里敲gcc提示找不到命令。
• 用「新建」逐条加，不要手动编辑那一长串文本。老版本的 Windows 里 Path 是一整行分号分隔的字符串，手动改容易把某条误删，删掉的是系统目录还好，删掉的是别的工具目录就得重装软件。
• 加完之后，已经打开的终端和 VSCode 全部关掉重开。环境变量是进程启动时读取的，老进程读的还是旧值。

3.4 用 gcc -v 验证，别信「应该装好了」

新开一个 PowerShell 或者 CMD，敲：

gcc -v g++ -v where gcc

第一条命令会打印一大段编译器的配置信息，最后一行能看到gcc version 8.1.0之类的字样。第二条验证 C++ 编译器也在。第三条最关键，它告诉你系统里到底有几个 gcc、按 PATH 顺序第一个是谁：

C:\mingw64\bin\gcc.exe

如果where gcc出来两行以上，说明机器上还装着别的编译器（以前装过的集成 IDE 自带的、某些数据分析工具捆绑的），这时候优先用哪个由 PATH 顺序决定，后面第 5 章会讲怎么处理。

4. C/C++ 插件与两份 JSON：c_cpp_properties.json 和 tasks.json

到这一步，编译器在系统层面已经能用了，但 VSCode 还不知道它的存在。编辑器靠扩展来识别 C/C++ 语法，靠两份 JSON 来知道「用哪个编译器补全」和「按什么参数编译」。

4.1 装 C/C++ 扩展

Ctrl + Shift + X打开扩展面板，搜C/C++，选安装量最高的那个（发布者那一栏是官方的那一个），点安装。装完右下角可能提示重启，重启一下。

装完的效果：打开.c文件，关键字有颜色，鼠标悬停在printf上能看到函数签名，写错语法会有红色波浪线。但注意，此时只是能写，还不能编译运行——补全和语法检查靠的是扩展自带的语言服务，跟真实编译是两回事。

4.2 c_cpp_properties.json：只负责补全和跳转，不负责编译

这份文件管的是 IntelliSense，也就是代码补全、错误提示、Ctrl + 点击跳转到头文件。它不参与实际编译，所以这里写错了，代码可能仍然能编译，只是补全一片红。

生成方式：Ctrl + Shift + P打开命令面板，输入C/C++，选「C/C++: 编辑配置(UI)」，会打开一个图形界面；在里面把「编译器路径」选成C:/mingw64/bin/gcc.exe，IntelliSense 模式选windows-gcc-x64。关掉这个界面，.vscode/c_cpp_properties.json就自动生成好了。

下面是我实际用的一份，改了两处路径，字段含义在代码后面逐个说：

{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "compilerPath": "C:/mingw64/bin/gcc.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "gcc-x64" }, { "name": "C++", "includePath": [ "${workspaceFolder}/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "compilerPath": "C:/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "gcc-x64" } ], "version": 4 }

逐字段说清楚，改的时候知道自己在改什么：

• compilerPath：整套配置里最关键的一项。写gcc.exe的绝对路径，路径分隔符用正斜杠/或者双反斜杠\\，写单个\会被 JSON 当转义符吃掉。C 语言配 gcc，C++ 配 g++。
• includePath：头文件搜索路径，${workspaceFolder}/**表示当前工作区递归全部包含，自己写的头文件放在子目录里也能跳过去。
• cStandard/cppStandard：告诉语言服务按哪个标准解析。写c17和c++17是稳妥选择；如果下载的 gcc 版本比较老，勾c++20会出现语法能过、编译不过的割裂感。
• intelliSenseMode：gcc-x64对应 64 位 MinGW。
• defines：预处理宏，_DEBUG加上之后，#ifdef _DEBUG的代码块会被高亮参与解析。
• version：文件格式版本，别动。
• 原始模板里可能还有一个windowsSdkVersion字段，纯 MinGW 环境用不上，直接删掉不影响。

C 和 C++ 两份配置分开写的好处是：只写 C 的时候，代码里误用 C++ 的语法会立刻报错，不会等编译才发现。

4.3 tasks.json：单文件编译的默认写法

这份文件管的是「按下编译命令时到底执行什么」。生成方式：随便打开一个.c文件，菜单「终端 → 配置默认生成任务」，在弹出的列表里选C/C++: gcc.exe 生成活动文件（C++ 就选 g++ 那个）。.vscode/tasks.json会自动生成：

{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: gcc.exe 生成活动文件", "command": "C:\\mingw64\\bin\\gcc.exe", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": "build", "detail": "编译器: C:\\mingw64\\bin\\gcc.exe" } ] }

args里这五个参数是整个任务的核心，拆开看：

• -fdiagnostics-color=always：让编译报错在终端里带颜色，错误行是红色、警告是黄色，长报错里能一眼扫到。
• -g：生成调试信息。加了它才能打断点、看变量；不加的话gdb加载进去没有符号表，断点打不上。
• ${file}：当前激活的源文件。这是单文件编译的标志，也是多文件场景下最大的坑。
• -o：指定输出文件名。
• ${fileDirname}\\${fileBasenameNoExtension}.exe：输出到源文件同目录，文件名跟源文件同名、后缀换成 exe。

label这行是任务名，编译时就是通过它来选任务的。problemMatcher: ["$gcc"]让 VSCode 能解析 gcc 的报错格式，把错误列到「问题」面板里，点一下跳到对应行。

编译：Ctrl + Shift + B，或者「终端 → 运行生成任务」。跑完在同目录下多出一个test.exe。运行要开集成终端（Ctrl + `），敲.\test.exe。前面那个.\不能省，PowerShell 出于安全考虑不会在当前目录找可执行文件，直接敲test.exe会提示找不到命令——这个报错和编译失败长得完全不一样，新手很容易误判成环境没配好。

4.4 多文件编译：改两个字段就够

单文件能跑之后，很快会遇到第二个文件。假设工程长这样：

test_vscode/ ├── main.c ├── math_utils.c └── math_utils.h

直接用默认的 tasks.json 编译，会报undefined reference to 'xxx'。原因很直白：${file}只编译了当前打开的那一个文件，其他.c根本没参与编译，链接阶段自然找不到函数实现。

改args里的两行：

{ "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", // 改动一：通配整个工作区的 .c "-o", "${workspaceFolder}\\${workspaceRootFolderName}.exe" // 改动二：输出到工作区根目录 ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": "build", "detail": "编译器: C:\\mingw64\\bin\\gcc.exe" } ] }

两处改动的作用：

${workspaceFolder}\\*.c把所有源文件一次性交给 gcc。Windows 下 MinGW 的 gcc 自己会展开通配符，不需要先经过 shell，所以路径里带反斜杠没问题。写 C++ 就把*.c换成*.cpp；混合语言的项目，把两行都写进args数组，gcc 和 g++ 会各管各的。注意这些注释行只是为了说明，实际存盘时删掉，JSON 标准不支持注释。

${workspaceRootFolderName}.exe让产物名字跟文件夹同名，输出到工作区根目录。好处是当工程里有多个带main的文件时，不会互相覆盖同名 exe。如果工程里恰好有不止一个main函数，编译会报multiple definition of 'main'，这是设计上就该报的错——一个可执行程序只能有一个入口，得把多余的main拆到别的文件夹去。

想同时保留「只编译当前文件」和「编译整个工程」两种任务，就在tasks数组里加第二项，label改成不同名字，编译时用命令面板选任务即可。

5. 踩坑排查：中文路径、PATH 顺序、链接报错这五件事

环境配完能跑，不代表以后不出问题。下面这五条是我在不同机器上真实遇到过的，每条按「现象 → 原因 → 解决」写，遇到同类症状可以直接对号入座。

5.1 现象：编译能过，一按 F5 调试就报错，报错信息里全是方块

原因：工程路径带中文。gcc对路径的处理还算宽容，但调试器加载符号表时对非 ASCII 路径支持不完整，报错信息本身也因为控制台代码页问题显示不出来，形成典型的黑匣子。

解决：把工程整个挪到纯英文路径，比如D:\code\test_vscode，然后 VSCode 重新打开新位置的文件夹。已经生成过的.vscode目录可以直接带过去，里面的${workspaceFolder}是变量，不用改。用户目录带中文（C:\Users\张三）的机器，桌面和文档目录都在中文路径下，别图省事往那儿放。

5.2 现象：外部终端gcc -v正常，VSCode 集成终端里提示「gcc 不是内部或外部命令」

原因：VSCode 是在配 PATH 之前启动的，进程继承的是旧的环境变量。改系统环境变量对已经运行的进程不生效。

解决：把 VSCode 完全退出（不是关窗口，任务栏和托盘里都要退干净），重新打开。如果还不行，检查是不是加错了目录——C:\mingw64和C:\mingw64\bin是两个完全不同的结果，前者加进去gcc一条命令都找不到。

5.3 现象：where gcc出来好几行，编译行为跟预期不一样，比如某个 C++17 特性报不支持

原因：机器上装着多个编译器，PATH 里排在前面的那个被优先使用。常见来源是以前装的集成 IDE 自带的 MinGW、某些开发工具捆绑的 gcc。这些版本往往比较老。

解决：两条路。一是回环境变量里把C:\mingw64\bin上移到最前面，让它优先命中。二是不动 PATH，直接在tasks.json的command和c_cpp_properties.json的compilerPath里都写绝对路径——这两处本来就支持绝对路径，写死了反而更稳，不受系统 PATH 顺序影响。我更倾向第二条，因为配置文件是跟着项目走的，换台机器路径对上了就行。

5.4 现象：单文件编译没问题，加了第二个源文件之后报undefined reference to '函数名'

原因：tasks.json里还是默认的${file}，只编译了当前活动文件，别的.c没参与编译和链接。这个报错特别容易被误判成「头文件没包含」或者「函数名拼错了」，实际上去看一眼args就明白了。

解决：按第 4.4 节把${file}改成${workspaceFolder}\\*.c。如果工程里源文件分布在多个子目录，通配符覆盖不到，就把每个目录都写进args，或者干脆上 CMake——不过那是另一个话题了，先用通配符把单层目录跑通。

5.5 现象：程序能跑，但终端里输出的中文是乱码

原因：Windows 控制台默认代码页是 GBK，而源文件一般存成 UTF-8，printf输出中文时两边编码对不上。

解决：三种做法，按侵入性从小到大。临时方案是在集成终端里先敲chcp 65001切到 UTF-8 再运行程序。稳定方案是在args里加一个-fexec-charset=GBK，让 gcc 把字符串字面量按 GBK 编码写进 exe。彻底方案是把源文件另存为 GBK，但不推荐，跨平台协作时会出问题。我自己用第二种，加到args数组里就行，一行的事。

5.6 现象：代码写对了，编辑器里还是一堆红色波浪线，补全也不出来

原因：c_cpp_properties.json里的compilerPath路径写错，或者includePath没包含自定义头文件所在目录，语言服务找不到头文件就整片标红。

解决：命令面板执行C/C++: 编辑配置(UI)，看「编译器路径」那一栏是不是真的指向C:/mingw64/bin/gcc.exe。改完保存，右下角状态栏会转一下重新解析。如果只是自定义头文件标红，往includePath里补一行${workspaceFolder}/include/**之类的路径即可。注意这份文件只管提示，标红不影响编译——判断到底能不能编译，永远以终端里的 gcc 输出为准。

6. 装完怎么验证跑通：三步走完再写业务代码

配置这东西，能跑一次不算数，得用一套固定动作把自己从玄学里捞出来。我现在的习惯是装完之后严格按下面三步验收，任何一步不对就停下来排，绝不带着半残的环境往下写代码。

第一步，在 VSCode 之外开一个全新的终端，跑gcc -v、g++ -v、where gcc。这一步只验证系统层，跟编辑器无关。如果这里就不通，问题一定出在解压层级或者 PATH，别往后查。

第二步，回到 VSCode，在集成终端（Ctrl + `）里再跑一遍同样的命令。这一步如果报「不是内部或外部命令」，说明 VSCode 进程没拿到新环境变量，重开编辑器，别去改配置文件。

第三步，用最小代码验证完整链路。在工作区建hello.c：

#include <stdio.h> int main(void) { printf("hello from mingw64\n"); // 只验证编译运行链路，不掺业务逻辑 return 0; }

按Ctrl + Shift + B编译，同目录出现hello.exe，终端里敲.\hello.exe，看到hello from mingw64就说明「编辑器 → 编译器 → 执行」整条链路通了。

接着验证调试，因为编译过和调试通是两回事。在printf那行左边点个红点下断点，按 F5，第一次会提示选择调试环境，选C++ (GDB/LLaunch)，会自动生成.vscode/launch.json。打开它，确认miDebuggerPath指向C:/mingw64/bin/gdb.exe，program指向${workspaceFolder}\\${workspaceRootFolderName}.exe或者你实际的 exe 路径。按 F5 之后程序停在断点处，能悬停看到变量，调试链路才算真正通过。

最后一张验收表，装完对着过一遍：

这套验收动作加起来不到五分钟，但能省掉后面几个小时的猜谜。从那以后我每次给新机器配环境，都会先写一个只有三行的 hello 程序跑通再动别的，配置文件也一律先从旧项目复制一份过来改，不从头手写——JSON 少一个逗号、多一个反斜杠，报错信息完全不会告诉你问题在哪。

希望这套流程能帮你少走几次弯路，装完安心写代码。

本文还有配套的精品资源，点击获取