1. 方案选型：两套配置我都建议你掌握
做 C++ 开发的人，基本绕不开这几个名字：VS Code、g++、CMake、gdb。工具链本身不复杂，但很多人卡在同一个节点——编译能过，代码能跑，按 F5 准备调试，结果要么弹“无法启动程序”，要么断点全部变成灰色空心圆。问题不在代码，而在构建和调试这两条链路没有打通。
这篇文章要解决的问题很具体：在 VS Code 里把 C++ 调试链路完整接上，重点讲两种主流配置方案——纯 g++ 命令行构建，以及 CMake 工程构建。你会看到 tasks.json、launch.json、CMakeLists.txt 这三个关键文件到底应该怎么写，每一步为什么这么写，改了某个参数会带来什么后果。适合刚切换到 VS Code 的 C++ 新人，也适合长期用集成开发环境、想搞明白 VS Code 调试原理的开发者。只要你把编译器和调试器之间“带调试符号的可执行文件”这个核心逻辑想清楚，后面所有配置都只是往这个模型里填参数。
为什么我要把两种方案都讲，而不是只推荐一种？因为它们的适用场景完全不同。纯 g++ 适合小规模、快速验证的场景，CMake 适合多文件、带第三方依赖的真实工程。实际工作中大概率两种都会碰到，与其每次都临时翻配置，不如一次把原理吃透。
1.1 纯 g++ 方案：单文件和小项目的轻量选择
如果你只是写一个 main.cpp，临时验证某个算法思路，或者给新同事演示语法，那纯 g++ 是最直白的方案。编译命令就一句：
g++ -g -O0 main.cpp -o main加-g会生成调试符号，gdb 才能把断点对应到源码行；加-O0是为了关闭优化，不然变量可能被优化掉，断点也会漂移。这两条是调试的基础，后面配置 tasks.json 时还会反复用到。
纯 g++ 方案的优点是好理解，整个构建链路是肉眼可见的。缺点也很明显：当项目膨胀到几十个源文件、多个目录的时候，手写编译命令不仅繁琐，而且容易漏文件、顺序错乱。这时候就该切换思路了。
1.2 CMake 方案：多文件工程的标配
CMake 不是一个“编译器”，它是一个构建系统生成器。你写一份 CMakeLists.txt，描述项目有哪些源文件、依赖哪些库、用什么语言标准，它就能在 Linux 上生成 Makefile，在 Windows 上生成 Visual Studio 工程文件，然后交给后端工具去真正编译。好处是跨平台、依赖关系清晰、维护成本低，所以它成了 C++ 社区事实上的工程标准。
在 CMake 工程里调试，本质上和纯 g++ 没有区别——调试器要找的还是那个“带 -g 符号的可执行文件”，只不过这个文件的位置变成了构建目录（通常是 build/）。很多人调试失败，就是因为还拿着小项目的思路，把 launch.json 里的 program 指向源码目录，自然找不到产物。
1.3 两种方案的差异对照
| 对比维度 | 纯 g++ 方案 | CMake 方案 |
|---|---|---|
| 适用规模 | 单文件、小项目、临时验证 | 多文件、多目录、第三方依赖 |
| 编译入口 | 手写 g++ 命令 | CMakeLists.txt 描述工程 |
| 调试配置难点 | 需要写全编译参数 | 需要定位构建产物路径 |
| 跨平台能力 | 每个平台要手工适配 | 一份 CMakeLists 覆盖多平台 |
| 上手成本 | 低 | 有一定门槛，但长期收益明显 |
我的建议是两条路都练熟。小项目用纯 g++ 可以少掉很多配置负担，大项目用 CMake 能让你把精力放在代码本身而不是构建脚本上。更重要的是，这两种方案的调试配置底层逻辑完全一致，你只要理解“调试器找什么”，切换起来毫无障碍。
2. 环境准备：把编译调试链路上的每一环都装齐
很多人配置失败，不是配置写法错了，而是环境本身缺东西。VS Code 只是个编辑器，它不会自带编译器，也不会自带调试器，更不会自动帮你把 C++ 标准库运行环境装好。所以开工之前先把这几样确认到位。
2.1 编译器与调试器的组合选择
Linux 和 macOS 自带了 gcc/g++ 或者 clang，通常不需要额外装编译器。Windows 下没有自带编译器，大部分人的选择是 MinGW-w64 或者 MSYS2。我个人的推荐是用 MSYS2，因为它的包管理很方便，一条命令能同时装好编译器、调试器等一整套工具链：
pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-gdb如果你用的是 MinGW-w64 的独立安装包，记得确认它的 bin 目录下真的有 gdb.exe。有些精简版本只装了编译器，没有带调试器，后面 launch.json 里怎么填都会报“找不到 gdb”。这个检查一分钟就能完成，在终端输入：
g++ --version gdb --version两个都能正常输出版本号，说明基础工具链没问题。macOS 上如果要用 gdb，还需要额外签名步骤，比较麻烦，大部分人直接改用 lldb 也可以，VS Code 的 C/C++ 扩展在 macOS 上原生支持 lldb，配置逻辑是一样的。
2.2 VS Code 内需要安装的两个关键扩展
第一个是微软官方出的 C/C++ 扩展（ms-vscode.cpptools），它负责语法提示、代码补全、智能感知，也是 launch.json 里cppdbg调试类型的提供者。没有这个扩展，断点、变量监视、调用堆栈这些调试功能都不存在。
第二个是 CMake Tools 扩展（ms-vscode.cmake-tools），它负责解析 CMakeLists.txt、选择编译器套件（Kit）、触发构建，还能一键启动调试。装好扩展后，命令面板（Ctrl+Shift+P）里才会出现CMake: Select a Kit、CMake: Configure这类命令。
如果你还装了像 Claude Code for VS Code 这样的 AI 辅助编码扩展，它们一般不会干扰调试链路，但要注意别让它们接管编译任务，构建这些事还是交给明确的编译任务来做更可控。
2.3 Windows 运行库缺失问题不能忽略
Windows 上有一个特别容易踩的坑：代码编译链接都成功了，一运行就弹窗说找不到 MSVCP140.dll 或者 VCRUNTIME140.dll。这个通常不是编译器的问题，而是目标机器上缺少 Microsoft Visual C++ Redistributable 运行库。
解决方案很直接，去微软官网下载 Visual C++ Redistributable 2015-2022 x64 装上就行。如果你的第三方依赖是 32 位的，可能还需要对应装 x86 版本。这个运行库几乎可以看作用 Visual Studio 工具链编译出的 C++ 程序的基本运行环境，MinGW 虽然有自己的运行库，但涉及一些第三方二进制依赖时仍然可能踩雷，所以不要省这一步。
2.4 CMake 下载与安装中的几个细节
CMake 官网提供了跨平台安装包。Windows 安装时有一个特别容易忽略的选项——“Add CMake to the system PATH”，很多人在安装时习惯性点了下一步，结果装完之后终端里cmake命令完全不可用，只能去安装目录里翻 bin 路径。
Linux 上如果在线安装不方便，可以提前在其他环境下载好官方发布的预编译包，解压之后把 bin 目录加入 PATH，效果和在线安装没有区别。装好之后用cmake --version确认版本。想要图形界面的话，也可以打开 CMake GUI，指定源码目录和构建目录，剩下的流程和命令行等价，只是多了一个可视化的选项面板。
3. 纯 g++ 方案：从编译任务到调试启动逐项配置
现在进入正题。我会用一个最小示例，把纯 g++ 方案的配置过程完整走一遍。建议你新建一个文件夹，最好放在纯英文路径下，配合操作。
3.1 先准备一个最小示例
在项目文件夹里新建 main.cpp，写一段简单的循环代码：
#include <iostream> #include <vector> #include <string> int main() { std::vector<std::string> names = {"Alice", "Bob", "Carol"}; int sum = 0; for (int i = 1; i <= 10; i++) { sum += i; } for (const auto& name : names) { std::cout << name << std::endl; } std::cout << "sum = " << sum << std::endl; return 0; }这段代码很简单，但足够演示断点、监视、变量展开等调试功能。后面讲“监视窗口观察字符串数组初始化后的内容”时，直接用这段代码当例子。
3.2 tasks.json：先解决“编译”这一步
VS Code 里的调试不是凭空启动的，按 F5 只是启动了调试器，调试器要加载的可执行文件需要提前编译出来。我们可以在 tasks.json 里定义一个编译任务，然后在 launch.json 里关联它，实现“按 F5 先编译再调试”。
用命令面板执行Tasks: Configure Default Build Task，生成 tasks.json 后改成下面这样：
{ "version": "2.0.0", "tasks": [ { "label": "build-demo", "type": "shell", "command": "g++", "args": [ "-g", "-O0", "${fileDirname}/${fileBasenameNoExtension}.cpp", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true } } ] }逐项解释一下：label是这个任务的代号，后面 launch.json 里的 preLaunchTask 要靠它来引用；command是要执行的程序，这里是 g++；args里的参数最关键的是-g和-O0。-g生成调试符号，-O0关闭优化。如果你之前写代码从来不加这两个参数，那就算配置一万遍 launch.json，断点也是灰色的，因为调试器不知道源码位置和机器指令的对应关系。
${fileDirname}和${fileBasenameNoExtension}是 VS Code 的预定义变量，分别表示当前打开文件的目录和文件名（不带扩展名）。所以这段配置的意思是：编译“当前打开的这个 cpp 文件”，生成同名 exe。这个写法适合多文件项目里逐个文件编译，但不适合把整个项目的所有源文件一起编译。后面会讲多文件怎么处理。
3.3 launch.json：让调试器找到可执行文件
接下来配置调试入口。点击左侧运行面板的“创建 launch.json”，选择模板“C++ (GDB/LLDB)”，然后替换成：
{ "version": "0.2.0", "configurations": [ { "name": "debug-demo", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "gdb", "preLaunchTask": "build-demo" } ] }这里面值得展开讲的参数不少。
type是cppdbg，这个值来自 C/C++ 扩展，表示使用该扩展提供的调试能力。program是调试器要加载的可执行文件路径，这里用变量拼出的路径，必须和 tasks.json 里编译产物的位置保持一致，这是最常见的错误来源之一。
preLaunchTask绑定了上面 tasks.json 里的build-demo，调试启动前会自动执行编译任务。如果编译报错，调试不会启动，这样保证你调试的一定是最新代码。
stopAtEntry如果设为 true，程序启动后会停在 main 入口，方便确认调试器是否正常连接。第一次使用建议设成 true，能看到调试器真正接管了程序，心理上就有底了。
miDebuggerPath是 gdb 的路径。如果你在终端里能直接敲gdb找到调试器，写 "gdb" 就行。如果不行，就要写完整路径，比如 Windows 下常见的是C:/msys64/usr/bin/gdb.exe。注意路径分隔符用正斜杠，反斜杠在 JSON 里要转义，很容易写错。
配置完成后，在 main.cpp 里随便打一个断点，按 F5，观察发生什么。如果一切顺利，程序会停在断点处，左侧出现变量监视区域。这一步成功，就说明纯 g++ 方案的链路已经打通了。
3.4 从单文件扩展：多文件和第三方库怎么处理
如果项目里有多个 cpp 文件，tasks.json 里的编译参数就要改。一种方法是把源文件全部列举出来，类似：
"args": [ "-g", "-O0", "main.cpp", "utils.cpp", "logger.cpp", "-o", "demo.exe" ]另一种想法是用通配符${workspaceFolder}/*.cpp，但这个在 Windows 的 cmd 下可能不会正确展开，g++ 收到的就是一个不存在的文件名，直接报编译错误。所以在 Windows 环境里，老老实实把源文件列出来最稳妥；文件实在多，就是时候考虑上 CMake 了。
如果需要链接第三方库，在 args 里追加-I头文件目录和-L库目录和-l库名。热搜词里有条命令g++ main.o -l/path/to/third_party/lib -lthird_party -o app，这种写法其实有点不规范，-l后面的参数应该是库名而不是路径，正确的拆法应该是-L/path/to/third_party/lib -lthird_party。库文件是libthird_party.a或libthird_party.so时，用-lthird_party就能找到。这个细节能让很多人少走弯路。
4. CMake 方案：用 CMake Tools 管理构建和调试
当项目开始有多个目录、多个源文件、第三方依赖，我强烈建议切换到 CMake。这部分的配置看起来多了一层抽象，但调试配置反而更简单——因为构建产物位置变得非常明确。
4.1 先搞清楚 CMake 和 Makefile 的区别
很多人第一次接触 CMake 时会困惑：Makefile 不也能构建吗？为什么非要 CMake？简单说，Makefile 是给 Make 这个工具读的构建规则，它直接描述“哪个源文件编译成哪个目标文件，最后怎么链接”。这套规则在 Linux 上还行，到了 Windows 上就尴尬了，路径分隔符、编译器参数、库文件后缀全都不一样，一份 Makefile 基本没法跨平台复用。
CMake 的思路是把“让用户描述项目”和“让工具处理平台差异”分开。你只需要在 CMakeLists.txt 里说明“我有一个名为 demo 的可执行程序，由 main.cpp 和 utils.cpp 构成”，CMake 会在你当前的平台上生成对应的构建文件（Linux 下是 Makefile，Windows 下可能是 Visual Studio 工程），再由实际的构建工具去编译。你写一次，CMake 帮你适配所有平台。CMake 里添加 strip 指令、设置安装规则、管理编译选项，也都是在这种高级抽象层里操作，比直接改 Makefile 要直观得多。
4.2 写一个最小但完整的 CMakeLists.txt
在项目根目录新建 CMakeLists.txt：
cmake_minimum_required(VERSION 3.10) project(demo) set(CMAKE_BUILD_TYPE Debug) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(demo main.cpp utils.cpp)一行一行拆开看。cmake_minimum_required声明了最低 CMake 版本，版本太低遇到新语法会直接报错。project定义项目名，这个名称会作为很多默认变量的一部分。set(CMAKE_BUILD_TYPE Debug)是调试的关键，它会让 CMake 在编译命令里自动加上-g，如果不写这一行，默认可能是空或者 Release，断点会失效。add_executable声明了一个名为 demo 的可执行目标，由哪些源文件组成。
这里有个容易被忽略的点：如果你在 VS Code 里通过 CMake Tools 配置了 Debug 构建类型，CMake Tools 会自动处理 CMakeLists.txt 里没有显式设置 CMAKE_BUILD_TYPE 的情况，因为它会在配置阶段传入。但为了可移植性，尤其是你自己在命令行敲cmake的时候，显式在 CMakeLists.txt 里写上 Debug 还是最保险。
4.3 CMake Tools 的实际操作流程
装好 CMake Tools 扩展后，打开项目文件夹，命令面板里依次执行：
CMake: Select a Kit，在弹出的列表里选择你本机的编译器，比如 g++ 或者 MinGW。这一步相当于 CMake 的编译器检测。CMake: Configure，CMake 会读取 CMakeLists.txt，生成构建系统文件，默认产物都在 build 目录下。- 点击 VS Code 底部状态栏的“Build”按钮，或者执行
CMake: Build，生成 demo 可执行文件。
在 VS Code 底部状态栏上，你能看到当前 Kit、构建类型、构建目标这几个入口。这里有个很实用的细节：如果状态栏显示的是 Release 或空白，点一下把它切换成 Debug，不然前面 CMAKE_BUILD_TYPE 的配置可能被覆盖，编出来的产物不带调试符号。
4.4 调试 CMake 构建产物
CMake Tools 本身提供了一个很便捷的调试入口，在“运行”面板的下拉选项里选择“CMake 调试”或者直接用 CMake Tools 的 Debug 按钮，它会自动匹配当前构建目标。这种方式省事，但对内部机制缺乏掌控感。
我更推荐亲手写一份针对 CMake 产物的 launch.json，因为这样你能彻底理解调试器到底加载了什么。在项目的 .vscode/launch.json 里写：
{ "version": "0.2.0", "configurations": [ { "name": "cmake-debug", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/demo", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "gdb", "preLaunchTask": "cmake-build" } ] }program指向 build 目录下的 demo。为什么是 build 目录？因为 CMake 默认要求“源代码目录和构建目录分离”，所有生成的中间文件和可执行文件都在 build 下。如果你用 CMake GUI 配置过，会发现构建目录和源码目录是两个完全独立的路径，就是这个原因。
为了让“按 F5 自动先构建再调试”，在 tasks.json 里加一个构建任务：
{ "label": "cmake-build", "type": "shell", "command": "cmake", "args": ["--build", "build"], "group": "build" }cmake --build build这条命令等同于在 build 目录执行make，但写法更通用，不依赖具体生成器。这样 F5 时，VS Code 先执行 CMake 构建，构建成功后再启动 gdb 加载调试器，流程就闭环了。
5. 调试操作与效率技巧：启动调试只是开始
配置跑通只是第一步，真正提升效率的是调试器本身的操作。这一部分讲几个实战中非常高频但也最容易被新手忽视的操作。
5.1 断点的三种进阶用法
普通断点很简单，点一下行号左侧就能打上，程序执行到这一行会停下来。但调试复杂逻辑时，普通断点往往不够用。
第一种是条件断点。在一个循环体里打断点，程序每次循环都停下来，非常烦人；如果你只关心当i == 50时发生了什么，右键断点，选择“编辑断点”，在表达式框里写i == 50。gdb 每一轮循环都判断一次，只有条件成立才真正中断，排查循环末期的问题特别好用。
第二种是命中次数断点。设置断点命中次数为 3，程序会跳过前两次，第三次停下。这在调试“某个操作每隔几次才出错”的场景很有价值，省得一次次按继续。
第三种是函数断点。在 C/C++ 调试面板里选择“函数断点”，输入函数名，不需要知道具体在哪一行，程序一调用这个函数就中断。调试库代码或者自己不太熟悉的大项目时，这是快速定位入口的神器。
5.2 利用监视窗口观察复杂变量
调试面板里的“变量”区域会显示当前作用域内的局部变量，但有时候你想看的是某个表达式的值，这时候“监视”区域更顺手。比如想看这个字符串数组初始化之后的内容：
std::vector<std::string> names = {"Alice", "Bob", "Carol"};在监视里添加names，展开后可以看到 size 为 3，逐项展开能看到每个字符串内容。想查看数组里特定位置的元素，可以直接写names[1]。如果你想看一个指针指向的内存区域，可以写*(ptr)或者*(ptr + 2)，调试器会按指向的数据类型解析内容。
VS Code 还提供了内存视图，可以切换按十六进制字节显示某个变量的底层数据。排查缓冲区溢出、字节序问题、或者自定义结构体内存对齐问题时，这个视图能让你直接看到变量在内存中的真实样貌，非常直观。
5.3 处理程序需要标准输入的场景
记得纯 g++ 方案里我建议externalConsole设为 false，因为 VS Code 的集成终端方便统一管理。但它有一个明显的局限：程序从标准输入读数据时，集成终端并不支持交互式输入，程序会一直卡在等待输入的状态，看起来像是死循环。
有两个解决办法。如果你就是想手动交互输入，把 launch.json 里externalConsole改成 true，程序会弹出一个独立系统终端，在那里可以正常输入。如果不打算交互，只是从固定文件读数据，更好的做法是让程序支持把文件名作为命令行参数传入，然后在 launch.json 的args里配置好文件名，这样既不用弹外部窗口，又能复现数据。
实际开发中我特别推荐第二种思路：命令行程序尽量设计成从文件读数据而非从标准输入读，调试体验会好很多。
5.4 快速定位崩溃现场
程序段错误或者访问违例时，调试器的处理方式比打印日志高效得多。在调试会话中打开 C/C++ 扩展的“断点”面板，你会看到“故障”类型的断点，对应 gdb 的 catch signal。启用后，程序弹出的瞬间调试器会立刻中断，调用堆栈面板会显示崩溃发生的位置和调用链。
这个技巧排查空指针、悬垂引用、越界访问特别有用。传统做法是到处加打印语句缩小范围，用故障断点直接一步到位，省下的时间不是一点半点。
6. 常见问题与排查技巧实录
配置过程中遇到问题是常态，很多问题现象一样，但根因完全不同。这里整理几个出现频率最高的问题，以及对应的排查顺序。
6.1 断点显示灰色空心圆
这是最经典的问题，没有之一。断点是灰色空心圆时，代码通常没有对应的调试符号，或者调试器加载的符号与当前源码对不上。
按顺序排查三件事：第一，编译命令里有没有-g参数；第二，改完代码后有没有重新构建，很多人按了 F5 但 preLaunchTask 配错，导致根本没触发编译；第三，launch.json 里的program路径和实际可执行文件路径是否一致。
还有一个细节容易被忽略：如果你当前打开的文件并不属于正在调试的程序，比如没有打开源文件，VS Code 也会让断点变灰。调试器只对已加载符号的源码文件响应断点，想验证的话，在 main.cpp 里打断点试试，通常就是好的。
6.2 变量在调试器里完全看不到或者显示“值不可用”
这个问题的本质是优化级别过高。编译器在 O2 或 O3 优化下，变量可能被优化掉，或者被搬进寄存器，调试器虽然能从寄存器里临时读出来，但经常不稳定，可能显示“无法访问”或者旧值。更极端的情况是断点行号和实际机器指令对不上。
解决办法就是回到 Debug 级别的编译选项。纯 g++ 方案里调整 tasks.json 的 args，CMake 方案里把CMAKE_BUILD_TYPE设为 Debug。一句话：调试和优化的组合本身就不友好，除非你有特殊需求，否则不要在高优化级别下调试。
6.3 报错“无法找到 gdb”或“miDebuggerPath 无效”
Windows 上最常见，原因通常是 MinGW 的 bin 目录没加入 PATH，或者 launch.json 里miDebuggerPath写成了反斜杠路径。多数情况下，在配置前先在终端确认gdb --version能不能找到，如果终端都找不到，那 VS Code 大概率也找不到。如果终端能找到，而 launcher 还是报错，建议不依赖 PATH，直接把完整路径写清楚，注意用正斜杠。
6.4 路径含中文导致调试失败
某些版本的 MinGW/gdb 在中文路径下会报错，比如 “Couldn't read symbols” 或者干脆打不开可执行文件。VS Code 本身不支持这个问题的彻底解决，最省事的方法是让项目和源码文件都放在纯英文路径下。这个建议听起来有点“土”，但确实能省掉大量解释不清的诡异错误。
6.5 编译链接成功但运行时提示 DLL 缺失
Windows 上运行 C++ 程序弹出找不到 MSVCP140.dll、VCRUNTIME140.dll 之类的报错，优先检查目标环境有没有安装 Microsoft Visual C++ Redistributable 2015-2022。按架构选择 x64 还是 x86 版本，装完后基本能解决。还有一种可能是你的程序里链接了某些第三方 DLL，但这些 DLL 没有放在同一个目录下，这属于部署问题，需要检查运行时目录。
6.6 CMake 构建的产物在 launch.json 里找不到
这个问题在从纯 g++ 方案切到 CMake 方案时特别常见。因为 CMake 默认把产物放在 build 目录下，而不是源码目录。比较高效的定位方法：先在 build 目录里看一眼可执行文件到底生成在哪个路径，确认无误后在 launch.json 里写成绝对路径或者${workspaceFolder}/build/xxx。如果用 CMake Tools 一键调试，它会自动处理这个逻辑，但手动写 launch.json 时就要自己负责了。
7. 经验沉淀：一套让我省心的调试自检流程
7.1 新环境两分钟自检流程
我换了新电脑或者给新同事搭环境，从来不会直接上大工程，而是用一个三行的 hello_world.cpp 先走一遍全链路。流程就三步：先在集成终端确认g++ --version、gdb --version能用；然后在 VS Code 里用纯 g++ 方案配一遍 tasks.json 和 launch.json，随便打断点按 F5；最后跑通之后，再引入 CMake 或者处理自己的真实项目。
这个流程的价值在于，每一步只会引入一个“新变量”。如果 hello_world.cpp 调试正常，说明 VS Code 的调试链路没问题，再出问题就一定是项目本身的构建配置问题，排查范围一下子缩小很多。我见过不少人跳过这一步，直接拿一个几百行还带第三方库的项目去配环境，一旦失败，连错在哪都分不清。
7.2 我对两种方案的最终选择心得
在实际使用中，我个人的习惯是这样的：单文件、临时脚本、算法验证，一律用纯 g++ 方案，省掉 CMake 的配置开销；正式项目，哪怕是只有几个文件的练习项目，只要可能持续迭代，就尽早引入 CMake。因为 CMake 的上手成本其实是恒定的，但你后面增加源文件、引入第三方库、扩展跨平台构建时，收益会越来越大。
调试环境问题真正让我头疼的次数并不多，但每次都能归结到同一个原则：调试器加载的可执行文件，必须是用-g编译出来的，路径必须准确。只要这两个条件成立，绝大多数调试问题都会自动消失。如果还不行，优先怀疑环境，比如 gdb 是否安装、运行库是否缺失，而不是反复改 launch.json 里的某个字段——把基础链路验证清楚之后，复杂项目也不会再让你头疼。
