VS Code调试C/C++成功的关键是gdb正常运行且源码行号匹配，需确保：编译器加-g参数、miDebuggerPath路径正确、tasks.json的label与launch.json的preLaunchTask严格一致。
VS Code 调试 C/C++ 的核心不是装一堆插件，而是让 gdb 能真正跑起来、且和你的源码对得上行号——这取决于三件事：编译器带 -g、调试器路径正确、launch.json 和 tasks.json 的任务名严格匹配。
确认 GCC 和 GDB 已就位且可调用
这是最容易卡住的第一步。VS Code 不会帮你装编译器，只负责调用它。
- 在终端（CMD/PowerShell/MSYS2）里运行
gcc --version和gdb --version，必须都能输出版本号；如果报“不是内部或外部命令”，说明 MinGW/TDM-GCC 没进PATH，或者安装时没勾选“添加到环境变量” - Windows 上推荐用 TDM-GCC 或 MSYS2 安装的
mingw-w64-ucrt-x86_64-gcc，避免用旧版 MinGW（不支持 C17/C++17 且 gdb 偶发崩溃） - 不要依赖 Visual Studio 自带的
cl.exe配gdb——二者不兼容，miDebuggerPath指向gdb.exe却用cl编译，断点永远不命中
tasks.json 必须生成带调试信息的可执行文件
tasks.json 不是摆设，它决定你调试的到底是“带符号的程序”还是“一串乱码地址”。
- 关键参数只有两个：
"-g"（生成调试符号）和"-o ${fileBasenameNoExtension}.exe"（输出带扩展名的可执行文件） - 别写
"-O2"或"-DNDEBUG"进去——优化会内联函数、删变量、重排逻辑，导致单步跳过、变量显示为<optimized out> - 如果你用中文路径或文件名（比如
测试.c），gdb在 Windows 下大概率读不到源码行，建议项目根目录用纯英文 - 任务
label值（如"C/C++: g++.exe 生成活动文件"）必须和launch.json里的preLaunchTask字符串完全一致，大小写、空格都不能差
launch.json 的 miDebuggerPath 和 program 路径要真实有效
很多人配置完发现 F5 按下去直接报错退出，八成是这两处填错了。
-
miDebuggerPath：如果已配好环境变量，填"gdb"就够了；如果没配，必须写绝对路径，比如"D:\TDM-GCC\bin\gdb.exe"——注意双反斜杠或正斜杠均可，但不能漏掉.exe -
program：值必须指向一个**已存在**的 .exe 文件。常见错误是写成"${fileDirname}/${fileBasenameNoExtension}"（缺.exe），或路径里混用了/和\导致 Windows 找不到 -
externalConsole设为true可以看到scanf/getchar等阻塞输入，但此时 VS Code 内置终端不捕获输出，调试时变量监视、断点停靠仍正常 - 别选
C++ (Windows)调试环境——那是给 MSVC 工具链准备的，底层调用vsdbg，和gdb完全无关
调试时变量显示 <optimized out> 或断点灰掉
这不是配置失败，是编译阶段就丢了调试信息，重来一遍比瞎调 launch.json 更有效。
- 删掉当前生成的 .exe 和 .o 文件，确保下次
Ctrl+Shift+B是全新编译 - 打开 VS Code 的「终端 → 集成终端」，手动执行一遍
gcc -g main.c -o main.exe，再运行gdb main.exe，输入list看是否能打出源码——如果不行，问题一定出在编译器或源码路径上 - 检查
c_cpp_properties.json里的compilerPath是否指向真正的gcc.exe（比如"D:\TDM-GCC\bin\gcc.exe"），否则 IntelliSense 会误判语法，但不影响调试本身 - 多文件项目务必用
tasks.json统一编译，不要靠 Code Runner 插件一键运行——它默认不加-g，也不生成可调试的 .exe
最常被忽略的一点：每次改完 tasks.json 或 launch.json，一定要关掉当前调试会话再重开，VS Code 不会热重载这些配置。另外，gdb 对 Windows 路径大小写不敏感，但对中文字符极度敏感——哪怕只是文件夹名里有个“（）”，都可能导致源码无法关联。
