C++调试时控制台一闪而过是因为程序执行完毕立即退出，导致终端进程关闭；Windows下cmd/PowerShell默认命令结束即关窗，macOS/Linux虽不关窗但光标回prompt易被误判为消失。
为什么C++调试时控制台一闪而过
这不是 VS Code 的 bug，而是程序执行完立即退出，终端进程随之关闭。Windows 下尤其明显——cmd.exe 或 PowerShell.exe 默认行为就是命令结束即关窗；macOS/Linux 虽不关窗，但光标回到 prompt 后容易误判为“没了”。关键点在于：VS Code 的调试器（cppvsdbg 或 lldb）本身不控制终端生命周期，真正决定“留不留”的是 program 进程是否阻塞、以及 launch.json 中的 console 配置是否生效。
确保 launch.json 的 console 字段正确设置
很多用户配了 launch.json 却依然闪退，是因为漏掉了这个关键项。它不控制编译，只控制调试运行时输出去哪、是否保留。
-
"console": "integratedTerminal"—— 输出进 VS Code 内置终端，程序退出后终端仍打开（推荐） -
"console": "externalTerminal"—— 弹系统终端（如 Windows Terminal），窗口由系统管理，不会自动关闭 - 千万别省略或写成
"console": "internalConsole"—— 这是调试专用控制台，不支持交互输入，且程序一退出就清空内容
示例最小可用配置：
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/build/main",
"args": [],
"stopAtEntry": false,
"console": "integratedTerminal",
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb"
}
]
}
让程序自己不退出（C++ 侧代码级处理）
调试器能停住，不代表你能看清输出。如果 main() 执行完就返回，控制台仍会快速滚动收尾。这时要在代码末尾加阻塞逻辑，但注意平台和标准兼容性：
立即学习“C++免费学习笔记（深入）”；
- Windows + MinGW/MSVC：
system("pause");最快，但不可移植，需#include <cstdlib></cstdlib> - C 标准方式：
getchar();—— 简单可靠，但若前面有未读取的换行符（比如scanf后），会直接跳过 - C++ 方式：
std::cin.get();或更稳妥的std::cin.ignore(std::numeric_limits<:streamsize>::max(), '\n'); std::cin.get();</:streamsize> - 跨平台可选：
std::this_thread::sleep_for(std::chrono::seconds(3));（需#include <thread></thread>和<chrono></chrono>），适合纯观察，不需交互
避免 preLaunchTask 编译失败导致调试根本没启动
“正在启动调试器”卡住几秒后闪退，常是因为 program 路径指向的可执行文件根本不存在——preLaunchTask 没成功编译，或者路径写成相对路径（如 "./build/main"）在某些工作区下解析失败。
-
program必须是绝对路径，推荐用${workspaceFolder}/build/main - 确认
preLaunchTask名称和.vscode/tasks.json中定义的一致，且任务实际执行成功（终端里能看到编译输出，无 error） - 临时加
"stopAtEntry": true，如果连main第一行都进不去，说明问题出在加载阶段（路径错 / 符号缺失 / 调试器路径无效），不是程序退出太快 - Windows 上用 MinGW 的
gdb，要检查miDebuggerPath指向的gdb.exe是否能独立运行（手动双击或命令行启动），常见静默失败原因是缺libwinpthread-1.dll等依赖
最易被忽略的是：你改了 launch.json，但没保存；或者焦点不在 C++ 源文件上就按了 F5，VS Code 根本没读到你的配置。
