1. 先搞清楚你装的是什么：VSCode本身不编译C/C++
很多新手上路的第一课不是学语法，而是先挨一顿“为什么我装完了还是跑不了”的毒打。你在VSCode里新建了一个hello.cpp，敲完代码，兴冲冲点右上角的运行按钮，结果终端一堆红色报错，什么g++: 未找到命令、The term 'g++' is not recognized。这时候你以为是VSCode坏了，换个编辑器再来一遍，会发现还是同样的结局。
原因其实特别简单：VSCode是一个编辑器，它的本职工作是帮你高亮代码、补全提示、管理文件，它本身不具备把C/C++源码变成可执行文件的能力。编译器（把代码翻译成机器指令的程序）和调试器（让你断点窥探程序内部状态的工具）是独立于VSCode存在的。
你去官网下载VSCode，它默认就是个“空壳”，装完之后连代码高亮都不全。很多教程直接让你装一个叫“C/C++”的插件，装完就以为环境配好了。这个插件名全称是C/C++ IntelliSense, debugging, and code browsing，它干的事情是给你提供代码智能提示、错误波浪线、跳转定义和调试界面，但真正的编译动作，它不负责。
这就是整个安装链路里最容易误解的一环：
- VSCode：负责给人看的界面和编辑体验
- C/C++插件：负责让VSCode“懂”C/C++语法，提供智能提示和调试入口
- 编译器（gcc/g++或cl）：负责把源代码编译成可执行文件
- 调试器（gdb或lldb）：负责在调试模式下控制程序执行、查看变量
所以这篇文章的完整路线是：装好VSCode、装好编译器、装好插件，再把三者用配置文件串起来。适合所有刚开始接触C/C++的同学，尤其是学校课程要用、打算法竞赛刷题、或者准备走C++开发路线但不知道从哪下手的人。文章里我会把每一步的“为什么”也讲清楚，不是照着点一遍就完事。
2. 下载与安装：别再装错了版本
2.1 官网入口和版本选择
去搜索引擎搜“VSCode下载”，第一条大概率是广告，我见过很多人点进冒牌网站下到一个带捆绑软件的安装包。认准唯一官网：code.visualstudio.com。这是微软的正式域名，页面底部有明确的版权信息，下载链接一般在页面明显位置。
进入下载页后，VSCode会根据你的操作系统自动推荐对应版本。Windows用户大概率拿到的是VSCodeUserSetup-x64-最新版本号.exe，这个就是正常的用户版安装包。
这里有一个很多人忽视的选择：User Installer和System Installer。官方下载页默认通常给的是用户版，它不需要管理员权限，装在当前用户的AppData目录下，适合个人电脑。系统版则可以装到Program Files，适合需要给多用户共享或某些需要管理员权限的场景。对绝大多数学习、刷题、开发C/C++的人来说，用户版就够了，它还能省去每次弹UAC的麻烦。不过有些第三方工具链（比如部分CMake插件、Ninja）在用户版下面偶发找不到环境变量的情况，如果你之后走到那一步再看要不要换系统版，不用提前纠结。
下载完安装包，双击进入安装向导。这里有几个勾选项：
- “添加到PATH”这个选项默认可能是关的，建议打开。它会帮你把
code命令注册到终端，之后在任意命令行输入code就能直接打开VSCode。 - “创建桌面快捷方式”看个人习惯。
- “将‘通过Code打开’操作添加到Windows资源管理器文件/目录上下文菜单”建议勾选，这样在文件夹右键就能直接VSCode打开，省事。
安装过程很快，几十秒就完成，不需要重启。
2.2 换成中文界面，别用一堆汉化包
很多教程会让你装“Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code”这个官方语言包插件，装完右下角弹提示切换语言。
但我的建议是：学习阶段直接保留英文界面。原因不是英文多高级，而是你后面去搜问题、查文档、看报错、看Stack Overflow，所有一手资料都是英文的。VSCode的菜单就那么几个关键词：File、Edit、Selection、View、Go、Run、Terminal、Help，一两天就熟了。等你看中文教程发现人家说的菜单项和你的界面对不上时，更崩溃。
如果你确实要中文，装完插件后按Ctrl+Shift+P，输入language，选择“Configure Display Language”，在里面把locale改成zh-cn，重启VSCode就生效。配置文件实际修改的是locale.json，你也可以直接在命令行用code --locale=zh-cn临时启动中文界面。
顺带说一句，这个语言包只改界面文字，不改任何功能逻辑，属于完全可逆的操作，不存在装了就不能改回英文的说法。
3. 编译器工具链：C/C++环境的重头戏
3.1 为什么我推荐MinGW-w64而不是其他方案
Windows上没有自带C/C++编译器，Linux有gcc，macOS有clang，但Windows要靠你自己装。常见选择有三个：
- MinGW-w64：GCC在Windows上的移植版，免费开源，C和C++都支持，教程最多，适合90%的初学者
- MSYS2：带一个包管理器，可以一键装GCC、CMake、Git等一堆开发工具，适合想折腾、打算长期搞C/C++开发的人
- Visual Studio Build Tools：微软官方编译器MSVC，Windows平台性能好，但配套的是Visual Studio风格，命令行使用对新手不太友好
对学习、刷题、写课程作业、跑算法竞赛模板来说，MinGW-w64是最稳的选择。有的学校让装老掉牙的Dev-C++，里面自带的就是老版本MinGW。但老版本MinGW（就是SourceForge上那个叫MinGW的项目）已经很多年不更新了，对新标准支持差，C++11之后的特性经常踩坑。所以我这里说的是MinGW-w64，后面有个“w64”，别下载错了。
3.2 快速获取MinGW-w64的两种方案
方案一是直接下载压缩包解压即可用。搜索“winlibs.com”，这个网站持续维护MinGW-w64编译器的预编译包，进入页面后找到“Win64”下的“UCRT runtime”版本，下载.zip文件就行。UCRT是较新的C运行时库，比老式的MSVCRT对C99/C++新特性支持更好，新装环境的直接选UCRT。
下载完解压到一个路径里，注意路径别带空格和中文，比如D:\mingw64。我之前见过有人解压到D:\Program Files (x86)\mingw64，结果后续CMake配置、Makefile解析各种诡异报错，排查半天。
方案二是用MSYS2。去www.msys2.org下载安装包，装好后打开MSYS2终端，运行：
pacman -S mingw-w64-ucrt-x86_64-gcc这条命令会把GCC编译器整套装好，之后在MSYS2安装目录下的mingw64\bin里能找到gcc.exe和g++.exe。
两种方案二选一。嫌麻烦的选方案一，打算以后装CMake、pkg-config、ninja这些工具的选方案二，本质上都是把编译器的bin目录暴露给系统。
3.3 配置环境变量并验证
不管哪种方案，最后一步都一样：把编译器的bin目录加到系统的Path环境变量里。
Windows 10/11的操作路径是：设置 → 系统 → 关于 → 高级系统设置 → 环境变量 → 在“系统变量”里找到Path→ 编辑 → 新建 → 填入你解压或安装出来的bin目录路径。
以方案一为例，如果你解压到D:\mingw64，那么填的是D:\mingw64\bin。填完之后一路点确定，然后重新打开一个新的终端窗口（不是让你把当前的cmd直接拿来用，因为环境变量不会自动刷新到已开的终端里）。
验证是否成功，新开终端输入：
gcc --version g++ --version gdb --version能看到版本号输出，就说明编译器工具链已经就绪。我遇到过最多的问题是“g++不是内部或外部命令”，八成是环境变量填错路径，或者填对了但终端没重开，以及改完环境变量VSCode没完全重启。这三个坑按顺序检查就行。
4. C/C++扩展：装完不等于万事大吉
4.1 核心扩展只有一个，其他是锦上添花
在VSCode左侧边栏点扩展图标（方块加四个小格子的那个），搜索C/C++，排在第一位、发布者是Microsoft的那个就是核心扩展，全称是“C/C++ IntelliSense, debugging, and code browsing”，下载量破亿。安装它。
这个扩展是微软官方套件，集成了三块能力：IntelliSense智能提示（包括自动补全、参数提示、悬停信息、错误波浪线）、调试（对接gdb/lldb）、代码浏览（跳转定义、查看引用、符号搜索）。
在基础上，还有几个插件可以一起装上：
C/C++ Extension Pack：微软官方打包的一个合集，里面除了核心扩展还有CMake工具、远程开发工具等，想省心可以装Code Runner：一个非官方的轻量运行插件，支持一键运行代码，适合刷题时快速跑测试样例，但它不走VSCode的调试配置，只是帮你把编译运行命令拼好执行Error Lens：把波浪线错误信息直接显示在代码行尾，不用鼠标悬停才能看到报错内容，对新手排错很友好Better C++ Syntax：提供更好的C++语法高亮，特别是模板编程、C++20特性那种复杂场景
对于刚开始接触的人，一个官方核心扩展加Code Runner就足够了。不要一口气装三十个插件，VSCode会变得奇慢无比，而且插件之间的功能还互相干扰。插件永远是解决问题的手段，不是目标。
4.2 装完扩展后的第一个小测试
新建一个文件夹，比如D:\code\c-study，用VSCode打开它。新建一个文件hello.cpp，写：
#include <iostream> int main() { std::cout << "Hello, World!" << std::endl; return 0; }保存（Ctrl+S）后，如果你的配置一切正常，你会看到#include <iostream>这一行没有出现红色波浪线，把鼠标悬停在std::cout上，会有智能提示弹出。这说明IntelliSense已经找到了编译器的标准库头文件。
如果这里出现了红色波浪线，比如提示“无法打开源文件iostream”，问题几乎都出在includePath配置上，我在第6节专门讲这个。现在先往下走，因为就算这里波浪线，也不影响你编译运行，后文会说为什么。
5. 三个配置文件，把“写代码—构建—调试”串起来
VSCode的C/C++环境坑过无数人的一部分就是这三个JSON文件：.vscode/tasks.json、.vscode/launch.json、.vscode/c_cpp_properties.json。它们各自负责一件事，一旦搞混，调试就乱七八糟。
5.1 tasks.json：负责编译
打开命令面板（Ctrl+Shift+P），输入Tasks: Configure Default Build Task，选择“C/C++: g++.exe build active file”，VSCode会自动生成一个.vscode/tasks.json。
这个文件的核心字段如下：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: g++.exe 生成活动文件", "command": "D:/mingw64/bin/g++.exe", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true } } ] }通俗解读一下这里的关键逻辑：
command：用哪个编译器args：传给编译器的参数。-g表示生成调试信息，没有这个参数，调试器就不知道哪一行对应哪条指令，断点会失效。${file}是被编译的当前文件，-o指定输出文件名problemMatcher：告诉VSCode如何从编译器的输出中识别错误信息，这样错误才能变成编辑器里的波浪线和问题面板条目group.isDefault：设为默认构建任务，这样按Ctrl+Shift+B时不会问你选哪个任务
需要注意的是，这段配置用的是编译器绝对路径。如果你不想写死路径，可以把command改成g++，前提是编译器已经加到系统环境变量。写绝对路径的优点是VSCode不会因为加载不到PATH里的内容而报错，缺点是换电脑、换编译器版本要改这一个地方。
5.2 launch.json：负责调试
按Ctrl+Shift+P，输入Debug: Open launch.json，选择“C++ (GDB/LLDB)”模板，会生成一个调试配置。这里最核心的配置项是program和preLaunchTask。
{ "version": "0.2.0", "configurations": [ { "name": "C/C++: g++.exe 生成和调试活动文件", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "D:/mingw64/bin/gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++.exe 生成活动文件" } ] }这里preLaunchTask填的字符串必须和tasks.json里的label完全一致，它的意义是“在开始调试之前，先自动执行一次编译任务”。这样你按F5时，VSCode会先帮你编译最新代码，再启动调试器。如果不配置这个字段，你改了代码直接按F5调试，调试的还是上一次的旧编译结果，这点特别坑。
externalConsole如果设成true，程序运行时会在弹出的小黑窗里显示输出，好处是支持cin交互输入不卡顿；设成false，程序跑在VSCode集成终端里，输出直接出现在面板下方。刷题时如果需要频繁输入测试用例，我建议把它设成true，能避开集成终端在读取输入时偶发的缓冲问题。
miDebuggerPath指向你的gdb.exe，这个路径要和你实际安装的MinGW路径对上。找不到gdb时，调试会启动失败，报错信息类似“无法启动gdb”。
5.3 c_cpp_properties.json：负责让编辑器“看懂”代码
按Ctrl+Shift+P，输入C/C++: Edit Configurations (UI)，VSCode会生成一个图形化的配置界面，同时在.vscode下生成c_cpp_properties.json。这个文件管的是IntelliSense、语法检查、跳转定义这些“编辑器层面”的事，不参与最终编译链接。
{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**", "D:/mingw64/include/**" ], "defines": [], "compilerPath": "D:/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }includePath告诉IntelliSense去哪找头文件，比如<iostream>、<vector>这些标准库头文件，就来自D:/mingw64/include。这就是前面说的“红色波浪线”能不能消失的关键。compilerPath填编译器路径，供IntelliSense模拟编译过程时参考宏定义和内置路径。
这里有个概念必须分清：IntelliSense报错不等于编译会失败，编译通过也不代表代码没有IntelliSense提示的问题。两者是并行体系，IntelliSense只是“尽力理解”你的代码，它的报错只能作为一个参考，真正的错误判定以编译器的输出为准。这一点能帮你免去一半的自我怀疑。
6. 智能提示失灵、补全错误与路径优先级
6.1 includePath的搜索优先级
很多人在顺序装完上面所有东西后，写到一个稍微复杂的项目还是遇到问题：代码能编译运行，但编辑器里一堆红波浪线；或者结构体成员补全不出来；或者跳转定义跳到奇怪的地方。
这些问题的根源就是c_cpp_properties.json里的includePath配置，以及它的搜索顺序。
includePath数组里的每一项代表一个搜索目录，IntelliSense会按数组顺序从前到后查找头文件。实战中我推荐的配置习惯是：
- 先放当前工作区的头文件目录：
"${workspaceFolder}/**"，这样你项目里自己的头文件优先被找到 - 再放编译器的标准库目录：
"D:/mingw64/include/**"或"${default}" - 如果有第三方库，比如OpenCV、Boost，再把它们的
include目录加在后面
数组顺序不是随便排的。如果你把编译器的标准包含目录放在最前面，而你项目里恰好有一个vector.h之类的自定义头文件，IntelliSense会优先命中标准库的vector，你的自定义类型就永远提示不出来。标准库路径和项目路径之间的优先级冲突，是“C/C++智能提示路径优先级”这个话题里最常见的一个坑。
另外一个隐藏机制是"${default}"这个特殊值，它会让C/C++扩展自动探测编译器内置的头文件路径。如果你发现代码有波浪线，但是不确定includePath该怎么写，可以把includePath改成：
"includePath": [ "${workspaceFolder}/**", "${default}" ]${default}会自动扩展成编译器安装目录里的标准头文件路径，省得手写路径还写错层级。
6.2 结构体成员补全错误与IntelliSense模式
“结构体成员补全错误”也是被提得很多的一个问题。现象是：你定义了一个结构体，然后用这个结构体类型声明了一个变量，接着敲变量名加.，弹出的补全列表里全是std::里的东西，或者干脆什么都不弹，或者弹出来的成员和实际定义对不上。
这背后通常是两个原因。第一个是intelliSenseMode配置不对，比如你用MinGW但intelliSenseMode还停留在windows-msvc-x64，导致IntelliSense拿了MSVC的语法规则去解析GCC的代码，碰到某些标准库实现（比如std::vector的内部成员）就会错乱。修法是把intelliSenseMode改成windows-gcc-x64。
第二个原因是IntelliSense索引没刷新。C/C++扩展的Tag Parser在识别头文件变更时有时候反应慢半拍，尤其你刚拉了一个新项目、或者代码里#include了刚创建还没保存过的头文件。这种时候按Ctrl+Shift+P，执行C/C++: Reset IntelliSense Database，清理索引重建，问题通常就消失了。
还有一个小概率问题是多个编译器共存造成干扰。比如系统装了Visual Studio的MSVC，又装了MinGW，compilerPath如果指向MSVC的cl.exe，但扩展模式却是windows-gcc-x64，这俩打架就会出现“补全出来的东西很奇怪”。为保证一致性，compilerPath、intelliSenseMode、includePath里的标准库路径，三者必须指向同一套工具链。
6.3 无法跳转到定义，怎么排查
跳转定义失灵的情况，按下面的链路排查，基本能覆盖所有可能：
- 确认C/C++扩展已启用，且当前打开的文件确实被识别为C/C++类型（右下角语言模式是不是“C++”，如果不是，点它切换）
- 确认目标头文件或函数所在的文件确实存在于工作区内，如果是点击
#include <iostream>这种标准库头文件，需要先确认includePath包含编译器标准库路径 - 按下
F12没反应时，试试右键文件 → “转到定义”；如果在.cpp文件里跳不到声明，去对应的.h文件里跳定义 - 如果项目较大、生成文件很多，IntelliSense可能因为索引超时还没建好符号表，等一会再试，或者手动执行一次
C/C++: Reset IntelliSense Database - 检查
c_cpp_properties.json里的compilerPath是否有效，如果编译器路径填错，IntelliSense完全无法解析任何代码，跳转功能也只会是一片空白
需要注意的是，IntelliSense的跳转和编译层面无关，代码不通过编译也能跳转，因为它做的是语法级别和符号级别分析，不是语义级别分析。模板展开、宏定义这些复杂情况下，跳转可能会不精确，这是工具的固有局限，不是配置错了。
7. 调试跑不通时的系统排查思路
7.1 从报错信息反向定位问题
环境配好之后，你最可能遇到的几个调试报错和对应的解决办法，我按高频到低频列一下：
| 报错/现象 | 主要原因 | 解决方式 |
|---|---|---|
无法打开 终端或g++ 不是内部或外部命令 | 编译器未加入PATH，或VSCode未重启 | 给环境变量加上MinGW的bin目录，完全重启VSCode |
| 调试启动后立即退出，无输出 | 程序编译失败，或preLaunchTask没配对 | 先手动Ctrl+Shift+B编译看有没有报错，检查launch.json的preLaunchTask是否与tasks.json的label一致 |
无法找到 program ... 或者没有调试信息 | program路径写错，或编译时漏了-g参数 | 确认输出文件名和launch.json里的program路径一致，确认tasks.json args包含-g |
MI Debugger 启动失败 | miDebuggerPath路径错误或gdb缺失 | 确认gdb.exe存在，路径用正斜杠或双反斜杠 |
| 断点打上但不生效（灰掉） | 编译时没有调试信息，或编译运行的二进制和当前代码不对应 | 清理旧的exe文件，重新编译，看看是否还提示“未找到调试信息” |
| 按F5提示“没有找到调试配置类型” | launch.json里的type字段写错 | 确认是cppdbg，不要手写成cppvsdbg |
索引式的排查表不能全背，核心思路是：先确认编译能过，再谈调试。调试器只能在编译产物的基础上做文章，编译都失败了，后面所有排查都是白用功。
7.2 退出代码、链接错误和生产环境里的花式翻车
VSCode终端里编译或运行结束时，偶尔会出现“c/c++退出代码”之类的提示。这个说法容易让人迷糊，代码不是“退出”了，而是程序执行完毕返回了一个退出码。退出码是操作系统层面约定俗成的信号：
- 退出码
0：正常结束 - 退出码
1：程序内部错误返回 - 负数（如
-1073741819）：通常是程序访问违规，常见是野指针、数组越界、栈溢出
在MinGW环境下，-1073741819对应十六进制的0xC0000005，就是Windows的访问冲突。看到这个码，第一反应不应该是“VSCode坏了”，而是去查自己的代码里有没有数组越界、指针没初始化就解引用这类问题。
编译链接阶段的报错更多：undefined reference to xxx表示你调用了函数但链接器找不到它的实现，常见于没把实现文件一起编译；multiple definition of xxx是同一个符号在多个编译单元里重复定义；fatal error: xxx.h: No such file or directory则是头文件路径没对上。
在处理这类问题时我始终坚持一条原则：报错信息是工具给你的最明确线索，不要跳过它去网上盲搜。先看第一行，在读第一行的路径和行号；再看最后一行，通常会有一个总结性的错误。中间堆了一大堆展开信息多半是模板实例化过程，新手可以先忽略。
7.3 一个快速上手的标准工作流
把环境配好之后的日常使用，我推荐这套工作流，能最大化减少“配置出问题”的概率：
- 每个项目一个独立文件夹，用VSCode打开这个文件夹，而不是打开单个文件。打开单文件时，
.vscode里的配置不会生效，很多初学者在这里栽跟头 - 写完代码保存，按
Ctrl+Shift+B手动编译一次，确认没有编译错误 - 按
F5启动调试，打断点，看变量 - 刷OJ或者做课程作业时，如果只是快速跑一下测试用例，可以装Code Runner直接右键运行；但想正经调试还是要用
F5
这里额外说一个我自己的使用习惯：我会把两个配置项单独提出来放在文件的首位，打开tasks.json时第一眼就能扫到：
- 编译器路径（
command） -o输出路径和文件名（args里对应的那一项）
因为90%的“环境崩了”都是编译器换路径、输出目录变化导致的，把这两行单独盯住，排查时间能缩短一半。
8. 进阶话题：远程开发、WSL和其他玩法
配好了本地C/C++环境，你其实已经解锁了VSCode最核心的用法之一。但如果你有以下几个方向的需求，配置还会有一些延伸。
8.1 在WSL里做Linux开发
很多算法竞赛选手和Linux开发者在Windows上写代码，但最终要部署到Linux环境。VSCode的官方远程开发扩展（Remote Development）支持直接连接WSL（Windows Subsystem for Linux）。
做法是：先在Windows上装好WSL（wsl --install），然后在WSL里用对应包管理器装g++：
sudo apt update sudo apt install g++ gdb在VSCode左侧扩展栏搜索“WSL”，装好之后，左下角绿色按钮会变成“WSL: Ubuntu”，点它可以远程打开WSL里的文件夹。这时候C/C++扩展会在WSL侧自动安装，includePath和compilerPath指向Linux路径，体验和本地几乎一样。
使用远程开发时要注意：编译和调试动作都发生在远端Linux环境里，不是Windows上。也就是说，你Windows本地的MinGW在WSL场景下完全用不上，这是两个独立的工具链环境，这点别混淆。
8.2 内置终端和外部工具链的配合
VSCode内置终端是一个隐藏利器。配置好环境变量后，在终端里直接敲g++ main.cpp -o main && ./main也能编译运行，效果和tasks.json调用的完全是同一个编译器。很多教程让新手用终端手动编译，但VSCode会自动生成tasks.json，因此两个入口可以随时切换，用什么都不冲突。
如果你的课程作业要求用Makefile或CMake组织多文件项目，我的建议是不要手写tasks.json里那一长串g++命令了，直接装CMake Tools扩展，它能自动解析CMakeLists.txt并生成对应的构建任务，再用F7一键构建。这条路更适合项目文件多、要引入第三方库的场景；单文件刷题用默认的tasks.json就够了。
8.3 关于AI编程助手的一些提醒
很多新人也会顺手装一些AI编程助手，比如GitHub Copilot、Codex、Claude Code的VSCode插件。这些插件能大幅提升编码效率，但也可能引入额外的环境变量要求和代理配置问题。如果某个AI插件在VSCode里无法使用或无法编辑代码，先检查是不是需要登录、是不是需要额外的网络连接、以及是否与C/C++扩展冲突。
这类插件本质上是把大型语言模型接到编辑器的补全和聊天接口上，属于编辑器层面的辅助，不会替代编译器本身。它们可以帮你生成代码骨架、学习语法、给出解释，但生成的代码能不能通过编译、能不能正确运行，依然取决于你配置的编译器工具链。用AI辅助编码时，最好保持一个习惯：让AI生成的代码必须自己能跑通才罢休，不要无限信任。
写在最后
从下载VSCode到真正能断点调试，其实就四个环节：编辑器、编译器、插件、配置文件。每一个环节都有陷阱，但反向来看，只要逐个验证——编辑器能打开、编译器能跑、插件识别代码、配置能串起来——你在这条路上能踩的坑基本就被堵死了。
我自己配这套环境踩过最大的坑是“工具链不统一”：编译器是MinGW的，IntelliSense模式用的是msvc，标准库路径又指向了Visual Studio的include目录。三个环节互相打架的结果就是，明明每个单项都正常，组合起来各种诡异。后来统一成“compilerPath指向哪套编译器，intelliSenseMode就用哪套模式，includePath就从哪套编译器里取”，这以后再没出过环境问题。
建议你装完环境之后，把下面的测试代码完整编译运行一遍：
#include <iostream> #include <string> #include <vector> struct Student { std::string name; int age; double score; }; int main() { std::vector<Student> students = { {"Alice", 20, 95.5}, {"Bob", 21, 88.0} }; for (const auto& s : students) { std::cout << s.name << " " << s.age << " " << s.score << std::endl; } return 0; }能编译通过、IntelliSense能正常提示name、age、score、断点能停在for循环里，你的C/C++开发环境就算是真正搭好了。之后无论是刷题、写课程设计，还是看开源项目，都有一个坚实的基础。
最后再啰嗦一句：配置文件这玩意，刚接触时会觉得又长又难懂，但了解它的逻辑之后会发现核心就是“告诉VSCode去哪里找编译器、怎么编译、怎么调试”这三件事。你把这三件事想通了，任何新机器、新平台，都只需要十分钟就能配好环境。
