Windows下VS Code配置C++开发环境：从零到调试

两个月前，我的一个学弟把"VS Code配置C++环境(Windows)"这个关键词反复搜了一晚上，最后发来一张截图：代码写好了，按F5运行，弹出来一句"g++不是内部或外部命令"。他照着三篇教程装到凌晨，越装越乱，最后甚至不知道该卸载哪个软件。

这个场景我太熟了。在Windows上用VS Code学C++，几乎每个人都会在环境配置这关被卡一次，而且多数时候不是能力问题，是教程把"编辑器"和"编译器"这两件事讲混了。VS Code本身只是一个编辑器，它不负责把代码变成exe，真正干这活的是编译器。明白这一点，配置过程就能少走一半弯路。

这篇文章不聊虚的，就讲清楚一件事：在Windows上怎么一步步把VS Code配成能编译、能调试的C++开发环境。包括工具链怎么选、环境变量怎么配、C/C++扩展的三个核心配置文件各是什么含义，以及我这些年实际踩过的几个高频报错和排查思路。适合刚接触C++的同学，也适合想用它刷算法题、写控制台小游戏但一直卡在环境问题上的人。

1. 先把角色分清楚：VS Code只是编辑器，编译器得自己装

1.1 VS Code和Visual Studio是两码事

先说一个很容易混淆的点：VS Code（Visual Studio Code）和Visual Studio是完全不同的两个软件。前者是微软出的免费、轻量、跨平台代码编辑器，插件生态丰富，启动快，适合写各种语言；后者是微软的重型集成开发环境（IDE），主要面向Windows平台的大型项目，体积大、功能全，自带MSVC编译器。

很多人以为"VS Code = Visual Studio的精简版"，其实不是。VS Code的设计哲学是"编辑器 + 扩展"，它默认只提供代码编辑、文件管理、终端这些基础能力，写C++需要的编译、调试、智能提示全部靠外部工具和扩展补齐。所以你会看到搜索结果里既有"VS Code"也有"Visual Studio Code"，指的都是同一个东西，别被绕晕。

如果你只是入门学C++、做算法题、写小工具，VS Code完全够用；如果是以后要做Windows桌面大型项目、依赖微软平台SDK，那Visual Studio会是更省心的选择。本文只讲VS Code这条路线。

1.2 编译器、调试器、语言服务器各管一段

一套能正常工作的C++开发环境，至少包含四件套：

• 编辑器：就是你看到的VS Code窗口，负责写代码、高亮、补全。
• 编译器：把C++源码翻译成可执行文件（exe）。Windows上常见的有GCC（g++）、MSVC（cl）、Clang。
• 调试器：让程序暂停在某一行，查看变量、单步执行。GCC搭配的是GDB。
• 语言服务器：负责智能提示、跳转定义、代码错误波浪线。VS Code的C/C++扩展自带一套IntelliSense引擎。

可以这样理解：编辑器是厨房案板和菜谱，编译器是灶台，菜谱写得再好，不点火永远端不出菜；调试器是温度计和试菜勺，让你知道菜做到哪一步了、味道哪里不对。而C/C++扩展像是一个在厨房里帮你找食材位置、提醒你火候不对的助手。

很多教程让你装完VS Code就直接搜"怎么配tasks.json"，却没人解释为什么需要这些文件。根源就在这儿：VS Code不知道你的编译器装在哪个路径、叫什么名字、怎么调用，所以需要配置文件来告诉它。

1.3 一句话理解配置流程

完整流程可以压缩成三句话：

1. 装一个编译器（本文用MinGW-w64，也就是g++）。
2. 把编译器路径加进系统环境变量，让终端能直接调用g++。
3. 在VS Code里通过C/C++扩展生成三个json文件：c_cpp_properties.json告诉插件"智能提示用哪个编译器"，tasks.json告诉VS Code"怎么编译"，launch.json告诉VS Code"怎么调试"。

把这三句话记住，后面所有的配置操作都是在往这三个目标上靠。网上那些长篇大论的教程，拆开看其实也就这几件事。

2. Windows下为什么推荐MinGW-w64而不是其他工具链

2.1 三条主要路线对比

Windows上给VS Code配C++工具链，主流选择有这么几种：

我的结论很直接：新手选MinGW-w64。原因有三个：第一，它解压即用，不依赖庞大的安装器；第二，g++的命令行习惯和Linux一致，以后转到Linux不需要重新学工具链；第三，教程和社区资料最多，遇到问题最容易搜到答案。

至于Visual C++ Redistributable（VC运行库），那是给MSVC编译出来的程序用的运行库，g++编译的程序一般不依赖它。如果你机器上装了某些软件提示缺少vc_redist，去微软官网装一个最新版就行，跟我们的MinGW-w64配置是两条独立路线。

2.2 选版本别踩坑：x86_64、posix、seh 是什么意思

MinGW-w64下载页面会出现一堆相似的文件名，新手很容易眼晕。记住这几个关键参数：

具体来说，以WinLibs下载页为例，文件名里通常包含mingw-w64-ucrt-x86_64-posix-seh这样的片段，意思就是"UCRT运行库、64位、POSIX线程模型、SEH异常处理"，这就是推荐组合。很多老教程还停留在win32线程模型，那个模型下std::thread可能没法正常使用，写多线程程序会莫名其妙报错，所以别贪图省事直接点第一个下载链接，确认这串标记再下。

2.3 推荐安装方式和下载渠道

这里给两条路径，任选其一。

路径A：WinLibs快速解压版

打开WinLibs官网，找到最新Release，下载MinGW-w64对应的zip压缩包（就是带posix-seh的那个）。下载完解压到一个好记的目录，比如C:\mingw64，解压后你会看到bin、include、lib这些文件夹，bin里面必须有g++.exe和gdb.exe。整个过程不需要运行安装程序，纯绿色解压。

路径B：MSYS2包管理器方式

下载MSYS2安装器，默认安装到C:\msys64。安装完成后从开始菜单打开"MSYS2 UCRT64"终端（注意是UCRT64，不是MSYS默认的那个），执行：

bash复制pacman -S --needed base-devel mingw-w64-ucrt-x86_64-toolchain

安装完成后，工具链实际在C:\msys64\ucrt64\bin目录下。MSYS2的好处是以后能用pacman统一安装第三方库，比如libcurl、spdlog之类的，对长期做C++开发的人来说非常方便。

路径A适合马上想跑通的急性子，路径B适合愿意多花十分钟换取长期便利的人。我个人的建议是：第一次配置图省事用A，后面发现要反复装库的时候自然就会转向B。两条路最终面对的是同一套g++/gdb，后续配置完全一样。

还有一条硬性建议：安装目录不要含中文，不要含空格。C:\mingw64这种最理想。路径边边角角的字符问题在后面配置json文件时会变成难以排查的坑，提前避开最划算。

3. 装完编译器先别急着写代码：环境变量和基础验证

3.1 PATH配置步骤，以及"改完必须重开终端"的坑

环境变量的作用，是让系统在终端里输入g++时能自动找到g++.exe。如果不配，你每次编译都要写完整路径C:\mingw64\bin\g++.exe hello.cpp，麻烦不说，很多工具默认调用g++命令会直接失败。

配置步骤：

1. 按Win + R，输入sysdm.cpl回车，打开系统属性，切到"高级"选项卡，点击"环境变量"。
2. 在"用户变量"区域找到Path，双击打开编辑器。
3. 点击"新建"，粘贴C:\mingw64\bin（如果你走MSYS2路线就填C:\msys64\ucrt64\bin）。
4. 一路点"确定"关闭所有窗口。

这里有一个99%的人都会踩的坑：改完环境变量之后，所有已经打开的终端窗口和VS Code都不会自动刷新。进程只在启动时读取一次环境变量，之后改了也不会感知。所以配置完必须把VS Code完全退出重新打开，最稳妥的做法是注销或者重启一次Windows。很多人配完Path发现还是提示"不是内部或外部命令"，不是路径写错了，就是忘了重启终端。

另一个提醒：网上有人推荐用setx命令设置Path，比如setx PATH "%PATH%;C:\mingw64\bin"，这个操作在极少数情况下会截断原有PATH，导致系统环境变量丢失，不推荐新手用。老老实实走图形界面最安全。

3.2 用命令行验证g++和gdb是否可用

配置完成后，新开一个终端窗口（如果是VS Code，用`Ctrl + `` 打开内置终端），依次执行：

bash复制g++ --version
gdb --version

正常会看到：

text复制g++ (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
...

如果提示"不是内部或外部命令"或者"无法将g++识别为cmdlet"，先对照下面的表格排查：

一个小技巧：在cmd里执行where g++，如果正确配置，会显示C:\mingw64\bin\g++.exe这条路径。显示出来了，说明系统已经能找到编译器，后面的事就好办了。

3.3 第一个hello.cpp：先手动编译一次

先不依赖VS Code的任何配置，用最原始的方式验证工具链。在任意目录新建一个hello.cpp：

cpp复制#include <iostream>
using namespace std;

int main() {
    cout << "Hello, C++!" << endl;
    return 0;
}

在VS Code内置终端里执行：

bash复制g++ -g -Wall hello.cpp -o hello.exe

-g表示生成调试信息，后面用GDB调试时必须要有；-Wall表示打开常见警告。执行完目录下会出现hello.exe，再运行：

bash复制./hello.exe

能看到Hello, C++!输出，说明编译器、链接器、运行环境全部正常，工具链层面已经成功。到这里，环境配置的大头已经完成，接下来要做的只是让VS Code"学会"替你执行这两条命令。

4. 三个json文件才是VS Code变IDE的关键

4.1 c_cpp_properties.json：告诉智能提示你的编译器是谁

在VS Code里先装好C/C++扩展（微软官方那个，搜"C/C++"，作者是Microsoft）。装完后按下Ctrl + Shift + P，输入"C/C++: Edit Configurations (JSON)"，回车，VS Code会在.vscode目录下生成一个c_cpp_properties.json。

这个文件的作用只有一个：告诉C/C++扩展的IntelliSense引擎，你的编译器和系统头文件在哪。它不影响编译，只影响代码编辑时的智能提示、跳转、错误波浪线。很多教程会让你手动列一堆includePath，其实没有必要，插件会从compilerPath自动推导标准库头文件。一份够用的配置长这样：

json复制{
    "configurations": [
        {
            "name": "Win64-GCC",
            "includePath": [
                "${workspaceFolder}"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "compilerPath": "C:/mingw64/bin/g++.exe",
            "cStandard": "c17",
            "cppStandard": "gnu++17",
            "intelliSenseMode": "windows-gcc-x64"
        }
    ],
    "version": 4
}

几个关键字段：

• compilerPath：填你的g++绝对路径。注意JSON和Windows路径里反斜杠是转义字符，建议全部用正斜杠/，g++和VS Code都认。
• cppStandard：C++语言标准。gnu++17表示GNU扩展的C++17，日常足够；想用新特性就写c++20。
• intelliSenseMode：必须选windows-gcc-x64，跟你的toolchain对应。

如果你使用MSYS2的UCRT64，把compilerPath改成C:/msys64/ucrt64/bin/g++.exe即可，其余不变。

4.2 tasks.json：把"编译"变成一键操作

按下Ctrl + Shift + P，输入"Tasks: Configure Default Build Task"，选择"g++ build active file"，VS Code会生成一个tasks.json。这个文件定义了一个"构建任务"，本质是把我们刚才手动敲的那条g++ -g -Wall hello.cpp -o hello.exe命令固化下来，以后按Ctrl + Shift + B就能自动执行。

json复制{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "cppbuild",
            "label": "CppBuild",
            "command": "C:/mingw64/bin/g++.exe",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/${fileBasenameNoExtension}.exe"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ]
        }
    ]
}

逐个解释关键点：

• label：任务的名字，随便起，但必须唯一，因为调试配置要靠它关联。
• command：直接用g++的绝对路径。这里用绝对路径比写g++更稳，避免某些环境变量异常时找不到命令。
• args：传给g++的参数。${file}是当前活动文件的完整路径，${fileDirname}/${fileBasenameNoExtension}.exe表示"当前文件所在目录下、与当前文件同名、后缀为.exe"的输出文件。比如活动文件是D:\code\hello.cpp，生成的exe就是D:\code\hello.exe。
• problemMatcher：填$gcc，编译报错才能显示在"问题"面板，点击错误信息还能直接跳到对应代码行。
• group.isDefault：设为true后，按Ctrl + Shift + B会直接执行这个任务，不再询问。

这里有个Windows路径的细节：args里我用的是正斜杠${fileDirname}/${fileBasenameNoExtension}.exe，而不是传统Windows习惯的反斜杠。原因是JSON字符串里反斜杠本身需要转义成\\，写起来丑还容易错；而g++在Windows下完全能识别正斜杠，cmd也支持，所以干脆全用正斜杠最省事。

配置好tasks.json后，打开任意.cpp文件，按Ctrl + Shift + B，看到终端自动执行编译命令，说明构建任务已经跑通。

4.3 launch.json：按下F5前它都做了什么

按F5（或先按Ctrl + Shift + D打开运行和调试面板，再点"创建launch.json文件"），选择环境时选"C++ (GDB/LLDB)"，VS Code会生成launch.json。这个文件负责指导GDB调试器如何启动你的程序。

json复制{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CppDebug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "C:/mingw64/bin/gdb.exe",
            "setupCommands": [
                {
                    "description": "为 gdb 启用整齐打印",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "CppBuild"
        }
    ]
}

重点字段：

• program：要调试的程序路径，和tasks.json生成的exe路径保持一致。这里同样用了变量，只要你先打开要调试的cpp文件再按F5，路径就能自动对应。
• miDebuggerPath：GDB调试器的路径，必须指向你实际安装的gdb.exe。最常出问题的就是这一项填错。
• preLaunchTask：填tasks.json里的label值（这里是CppBuild）。它的意思是：按F5时，先执行编译任务，编译成功后再启动调试。这样你永远调试的都是最新代码，不用手动先编译一遍。
• externalConsole：false表示程序在VS Code内置终端运行，优点是和编辑器一体、不容易乱码；true表示弹出一个独立cmd窗口运行，适合需要标准输入交互的程序，但中文显示问题会更多。
• stopAtEntry：true的话，调试启动后先停在main函数入口处，方便初学者逐步观察。

这段配置最巧妙的地方就在preLaunchTask。它把"编译"和"调试"串联成了一条流水线：按下F5 → 先编译 → 编译通过 → 启动GDB → 加载exe → 停在断点。VS Code本身不编译也不调试，但它通过配置文件把两个独立工具拧成了一条链。

4.4 三个配置文件是怎么配合起来的

用一张表总结三者的分工：

它们不是三个孤立文件，而是围绕同一套工具链（g++/gdb）的三份说明。c_cpp_properties.json负责"理解代码"，tasks.json负责"生成代码"，launch.json负责"运行并检查代码"。配好这三样，VS Code才算真正从编辑器变成了支持C++开发的工作台。

5. 我把高频报错按排查链路过了一遍

5.1 终端报"g++不是内部或外部命令"，可能错在哪几步

这是配置环境最常见的一道坎，我建议按下面的顺序排查，而不是直接百度一通乱试：

1. 确认编译器真的装好了：打开C:\mingw64\bin，看看里面有没有g++.exe。没有就说明下载的包不对或没解压完整，回到第2.3节重新下载。
2. 确认PATH里的路径指向了bin：环境变量里新增的是C:\mingw64\bin，不是C:\mingw64。少写\bin，系统根本找不到。
3. 确认环境变量是否生效：新开一个cmd窗口，执行echo %PATH%，看输出里有没有C:\mingw64\bin。没有的话，说明你编辑完可能没有点确定，或者窗口是在编辑之前打开的。
4. 终极测试：在终端直接执行C:\mingw64\bin\g++.exe --version。如果这能输出版本，说明工具链没问题，纯粹是PATH的事；如果连这个都提示找不到，那基本可以确定bin目录里压根没有这个文件。

我自己见过最多的情况是第3种：改完Path忘了重启VS Code，结果在旧进程里怎么试都不行。先退出所有终端和VS Code，再重新打开，多半能解决。

5.2 运行exe窗口一闪而过

双击编译好的exe，控制台窗口闪一下就消失，什么都来不及看。这不是编译有问题，是控制台程序执行完自动关闭，Windows没给你留看结果的时间。

三个解法按推荐程度排序：

• 在VS Code终端里运行，而不是双击exe。终端里程序结束后窗口不会关闭，输出留得住。
• 程序结尾加std::cin.get();，程序会停住等待回车再退出。
• 用调试模式（F5）启动，GDB控制程序生命周期，窗口不会秒退。

前面提到的system("pause");虽然也能用，但它依赖Windows特有的dos命令，跨平台代码里写它会让程序没法在Linux编译，我不建议大家养成这个习惯。

5.3 控制台中文乱码的根源与对策

现象很经典：代码里写了cout << "你好"，编译通过，运行exe时中文变成一堆乱码。

根源在于编码不一致：VS Code保存源文件时默认UTF-8，g++也按UTF-8处理字符串字面量，所以exe里的字节是UTF-8编码；但Windows的cmd控制台默认代码页是GBK（936），它拿到UTF-8的字节流，用GBK去解析，自然就是乱码。

最省事的方案是在main函数开头加两行：

cpp复制#include <windows.h>

int main() {
    SetConsoleOutputCP(CP_UTF8);
    // ...
}

SetConsoleOutputCP(CP_UTF8)把控制台输出代码页切成UTF-8，让控制台按字节流的真实编码去显示。实测在Windows 10/11上稳定有效。另一种轻量办法是运行exe前在终端手动执行chcp 65001切换代码页，效果一样，但每次都要手动敲，麻烦一些。

不要把源码文件编码改成GBK来迁就控制台，那种做法换一台机器就乱，治标不治本。现代C++项目的编码默认UTF-8是共识，控制台的显示问题在Windows上解决即可。

5.4 Remote-SSH连不上/提示"未能下载VS Code服务器"

如果你用Remote-SSH插件连接远程Linux主机，比如局域网内一台10.10.8.149的机器，连接时卡在"正在下载VS Code服务器"，最后报failed to fetch，这说明本地到远端的SSH协议没问题，问题出在远端下载服务器程序失败。

原因是这样的：VS Code连接远程主机后，需要在远端部署一个约几十MB的server程序，这个下载动作发生在远程主机上，由远端主动访问微软的更新服务器。如果远程主机访问外网不稳定、被防火墙拦截，或者缺少curl、wget、tar这些基础工具，下载就会失败。

排查顺序：

1. 直接SSH登录远端，手动测试网络：

bash复制curl -I https://update.code.visualstudio.com

如果卡住或超时，说明远端访问微软服务器有问题，换个网络环境再试。

2. 检查远端有没有curl和wget：

bash复制which curl wget tar gzip

缺哪个就装哪个（例如Ubuntu下用sudo apt install curl tar gzip），装完重连一次。

3. 如果远端网络就是不稳定，可以离线手动部署server。具体做法是：在本地VS Code里按Ctrl + Shift + P输入"About"，记下Commit ID（一长串20位十六进制字符）。然后在本地浏览器打开这个地址：

text复制https://update.code.visualstudio.com/commit:<你的CommitID>/server-linux-x64/stable

下载得到一个tar.gz文件，scp传到远端：

bash复制scp vscode-server-linux-x64.tar.gz user@10.10.8.149:~/

再SSH登录远端执行：

bash复制mkdir -p ~/.vscode-server/bin/<你的CommitID>
tar -xzf vscode-server-linux-x64.tar.gz -C ~/.vscode-server/bin/<你的CommitID> --strip-components=1

完成后重新在VS Code里连接，远端已经有现成的server，就不会再触发下载了。

另外，新版VS Code在Remote-SSH的设置里提供了一个"允许本地下载服务器并复制到远端"的选项，在Settings里搜索remote SSH相关的下载选项，开启后也可以在远端下载失败时走本地复制这条路。具体设置项名称随版本略有不同，以你在设置面板里搜到的为准。

5.5 调试时提示找不到程序或者无法启动

按F5进入调试后，如果提示"无法启动调试"或找不到exe，多半是两种情况：

第一种，program指向的exe不存在。这说明preLaunchTask没有正常工作。去终端看tasks.json的编译命令是不是真的执行了，或者program和tasks.json生成的exe路径是否一致。我见过很多人改过tasks.json的输出目录，但launch.json里的program还指向旧路径，两者各说各话。

第二种，miDebuggerPath写错或GDB缺失。检查C:\mingw64\bin\gdb.exe是否存在，launch.json里是否写的正斜杠路径。如果MinGW包本身不含gdb，回到WinLibs下载完整工具链替换。

还有一个调试新手常踩的坑：想打断点，结果发现断点根本不停。先确认两点：一是tasks.json的args里有-g参数，没有调试信息GDB无从停起；二是打断点的代码没有被编译器优化掉，比如设断点的那一行是空行或者只有大括号。这两点排查完，断点基本就正常了。

6. 配置文件跑通之后，多文件项目怎么组织

6.1 单文件能跑了，多文件怎么办

tasks.json里的${file}变量"当前打开哪个文件就编译哪个"，这个逻辑对单个cpp文件很舒服，但项目一复杂就行不通了。比如main.cpp要用tools.cpp里的函数，光编译main.cpp会报"undefined reference"链接错误。

最简单的改法，是在tasks.json的args里显式列出所有源文件：

json复制"args": [
    "-g",
    "main.cpp",
    "tools.cpp",
    "-o",
    "${workspaceFolder}/app.exe"
]

编译时把tools.cpp也一起传给g++，链接阶段就能找到函数实现了。这个方案在小项目里够用，缺点是每新增一个cpp文件都要手动改tasks.json，文件名一变就乱。

第二种方案是在终端手动编译：

bash复制g++ -g main.cpp tools.cpp -o app.exe

看起来和上面的json没啥区别，但好处是不用维护配置文件，适合只有两三个文件的临时项目。我早期写小工具的流程就是：写代码、切到终端敲一条编译命令、运行、看结果。

第三种方案是分步编译和链接，先把每个cpp编译成目标文件（.o），再统一链接：

bash复制g++ -c main.cpp
g++ -c tools.cpp
g++ main.o tools.o -o app.exe

这个过程对理解编译原理很有帮助，日常使用显得啰嗦。真正项目文件一多，就走下面的CMake路线。

6.2 更进一步：用CMake管理工程

当源文件超过五六个，或者还要引入第三方库时，手写g++命令会变得非常痛苦。这时候上CMake是正解。

先在VS Code里安装CMake Tools扩展，然后在项目根目录创建CMakeLists.txt，一个最小示例：

cmake复制cmake_minimum_required(VERSION 3.16)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(app
    main.cpp
    tools.cpp
)

在VS Code里按Ctrl + Shift + P，执行"CMake: Select a Kit"，选择你的g++套件，底部状态栏就会出现构建按钮。点一下，CMake会自动帮你完成配置和编译，源文件列表在CMakeLists.txt里维护，再也不用改tasks.json。

命令行方式也顺手提一下，在某些没有VS Code的环境里会用：

bash复制cmake -S . -B build -G "MinGW Makefiles"
cmake --build build

-G "MinGW Makefiles"是为了让CMake认识MinGW工具链。如果你用的是MSYS2的UCRT64终端，则可能要改成-G "Unix Makefiles"，这是环境差异，不用纠结，按报错提示调整即可。

6.3 环境配好之后，值得花时间做的事

把这套环境跑通之后，我建议趁热打铁做几件事，把环境优势转化成实际编程能力。

第一，用调试器完整走一遍程序。随便写个冒泡排序，在交换元素的那一行打上断点，单步执行，观察数组每次swap前后的变化。这一步比看十篇教程都管用，你会第一次"看见"程序在内存里到底做了什么。

第二，写一个控制台小游戏。猜数字、贪吃蛇、俄罗斯方块都行。小游戏涉及循环、随机数、条件判断、输入处理，还有最基本的状态管理，把一个能跑的game loop写出来，C++的很多概念就串起来了。

第三，按需学习工具链的进阶用法。比如用spdlog库写日志、用CMake把项目组织成src和include的结构、甚至用C++ API把数据写入数据库。环境不是瓶颈之后，真正决定效率的是你对编译和构建流程的理解深度。

我个人在实际配置中还有个习惯：把这三个json文件存成个人配置模板，放到一个固定目录里。每次换电脑、换系统、或者帮别人配环境，直接把模板拷贝过去改一下compilerPath路径就完事，不用每次从头点一遍界面。VS Code的json文件支持注释，我习惯在文件里写上"此配置基于MinGW-w64 UCRT工具链，如更换MSYS2请同步修改所有C:/mingw64路径"这样的醒目注释，防止三个月后自己看着路径发呆。

配置C++开发环境这件事，说穿了就是让VS Code知道编译器在哪、怎么调用、调试器在哪。把今天这套流程照抄一遍，先让hello world跑起来，再去研究细节，你会发现后面所有高级配置都建立在这套基础逻辑之上。还没有跑通的同学，关掉那些收藏夹里吃灰的教程，照着这篇文章从头走一遍，多数情况下十分钟之内你就能看到那行Hello, C++!。