能调试的前提是launch.json中program、midebuggerpath和prelaunchtask字段必须准确指向真实存在的可执行文件、gdb.exe绝对路径及tasks.json中完全匹配的label；路径需注意反斜杠双写、.exe后缀不可省略、大小写与空格须严格一致。
能调试的前提不是装了插件，而是 launch.json 里每个关键字段都指向真实存在的东西——尤其是 program、miDebuggerPath 和 preLaunchTask。配错任意一个，F5 就直接报 “Unable to start debugging” 或 “Program does not exist”。
program 路径必须和编译输出完全一致
这是最常踩的坑：你让 tasks.json 把 hello.cpp 编译成 hello.exe 放在 ${fileDirname} 下，那 launch.json 的 program 就得写成 "${fileDirname}\${fileBasenameNoExtension}.exe"（Windows）或 "${fileDirname}/${fileBasenameNoExtension}"（Linux/macOS）。
- 别用
${workspaceFolder}硬套，除非你强制把所有输出都扔进根目录 - 别漏掉
.exe后缀，Windows 下缺它就找不到可执行文件 - 路径中反斜杠要双写（
\），否则 JSON 解析失败 - 如果用了
g++ -o build/hello.exe，那program就得对应写"${fileDirname}/build/${fileBasenameNoExtension}.exe"
miDebuggerPath 必须是 gdb.exe 的绝对路径
VS Code 不会自动从 PATH 查 gdb，它只认这个字段填的完整路径。哪怕你系统 PATH 里有 gdb.exe，不填这里照样报错。
- 典型路径如：
"D:\mingw64\bin\gdb.exe"或"C:\MinGW\bin\gdb.exe" - 路径错误时，控制台会显示类似
Could not find the debugger executable specified in 'miDebuggerPath' - 别写成
gdb或gdb.exe（没路径），也别写成D:mingw64in（没指定可执行文件） - 确认该路径下确实存在
gdb.exe，右键属性看“目标”字段最稳妥
preLaunchTask 名称必须和 tasks.json 中 label 完全匹配
VS Code 是靠字符串精确匹配来触发构建任务的。launch.json 里的 preLaunchTask 值，必须和 tasks.json 里某个 task 的 label 字段一模一样，包括大小写和空格。
- 比如
tasks.json写的是"label": "g++ build active file"，那launch.json就得写"preLaunchTask": "g++ build active file" - 常见错误：tasks.json 里 label 是
"task g++"，launch.json 却写成"g++"或"build" - 匹配失败时，F5 会弹窗提示 “Could not find task ‘xxx’”，点“配置任务”会重新生成 tasks.json，但旧配置不会自动覆盖
- 建议 label 全小写+短横线，例如
"label": "build-cpp"，避免空格和特殊字符
externalConsole 和 stopAtEntry 影响调试体验
这两个参数不决定能否启动调试，但直接影响你能不能看到输出、要不要手动关窗口。
-
"externalConsole": true：弹独立 CMD 窗口，程序结束不自动关闭，适合带cin或需要暂停看结果的场景 -
"externalConsole": false：用 VS Code 内置终端，程序退出后窗口立即消失，容易错过输出 -
"stopAtEntry": true：一启动就在main第一行断住，适合想确认环境是否真跑起来了 -
"stopAtEntry": false：跳过入口，只在你设的断点停；但如果程序一闪而过又没断点，就啥也看不到
真正卡住人的从来不是“怎么写”，而是路径拼错、名称不一致、后缀遗漏这些细节。调试器不会告诉你“你少写了 .exe”，只会沉默地失败。多花十秒检查 program 和磁盘上实际生成的文件名是否完全一致，比反复重启 VS Code 有效得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
