根本原因是C程序运行完立即退出，终端无内容可留；解决方式包括：末尾加getchar()、system("pause")（需#include<stdlib.h>），或F5调试时用integratedTerminal保持窗口。
VSCode 里 C 程序一跑完黑框就消失，不是 VS Code 坏了，是进程退出后终端没东西可留——它本就不该“等你按回车”。
为什么 C 程序在 VSCode 终端里执行完就闪退
根本原因和 Python、Node.js 一样：gcc 编译出的可执行文件（比如 a.exe）本身是命令行程序，运行完立刻退出，操作系统终端（CMD/PowerShell/Terminal）默认不阻塞。VSCode 集成终端只是容器，不会主动拦截这个行为。
常见误判点：
- 以为是
tasks.json或launch.json配错了，其实配置只影响“怎么启动”，不改变“程序自己是否退出” - 双击生成的
.exe文件，或右键用“在外部终端中运行”，这完全绕过 VSCode 控制，纯属系统终端行为 - 在代码里写了
system("pause")却没加#include <stdlib.h>，导致编译失败，程序根本没跑起来就退出了
让 C 程序输出停留的三种可靠方式
别指望终端自动挂住，得让程序自己“卡住”或让终端“知道该留着”。优先级从高到低：
立即学习“C语言免费学习笔记（深入）”；
-
改代码末尾加
getchar()：最轻量、跨平台、无依赖。在return 0;前插入一行getchar();，程序会停在终端等待一次按键输入 -
用
system("pause")（仅 Windows）：需#include <stdlib.h>，且确保链接器子系统设为控制台（否则可能无声失败）。注意：它调用的是 CMD 的pause命令，不能在 WSL 或远程 SSH 终端里用 -
调试模式下配
"externalConsole": false：在launch.json中把"externalConsole"设为false（默认值），并确保"program"指向正确路径（如"${fileDirname}/${fileBasenameNoExtension}.exe"）。这样调试器会接管终端生命周期，程序退出后窗口仍保留
tasks.json 和 launch.json 容易踩的坑
很多人以为改了配置就能解决闪退，结果白忙活。关键点其实是：这些配置只在特定触发方式下生效。
-
tasks.json里的任务（比如用gcc编译）默认是“一次性任务”，VSCode 执行完就收终端——除非你显式加"isBackground": true并配好problemMatcher，否则它不会等你手动敲命令 -
launch.json的配置只对 F5 调试 生效；如果你点的是右键菜单里的“Run Code”或 Ctrl+F5（运行而不调试），那它完全不参与 -
"program"路径写错（比如漏掉.exe后缀、路径含空格没引号、用反斜杠没转义），会导致调试器找不到可执行文件，直接报错退出，根本看不到输出 - Windows 下若用 MinGW，
"miDebuggerPath"必须指向真实存在的gdb.exe，否则调试启动失败，终端一闪而过还报红字
真正起作用的终端驻留逻辑
VSCode 集成终端本身没有“停留开关”，它的生命周期由两件事决定：你用什么方式启动它，以及你执行的命令是否阻塞。
- 手动打开终端（Ctrl+Shift+`）→ 输入
./a.exe→ 它不会关，但光标回到 prompt，容易误以为“没了”。这时加个read -p "Enter to continue"（macOS/Linux）或pause（Windows PowerShell）才真正卡住 - 用
launch.json+ F5 启动调试，且"console": "integratedTerminal"（C/C++ 调试器默认就是这个），终端会在程序退出后保持打开，并显示退出码和 stderr 输出——这才是观察错误堆栈最稳的方式 - 别碰
"externalConsole": true，尤其在 Windows 上：它会弹独立 CMD 窗口，而 CMD 默认行为就是命令结束即关闭，反而更难控制
最常被忽略的一点：终端“看起来闪退”，有时根本不是终端问题，而是程序自己崩溃了（比如段错误、未初始化指针），还没来得及输出就退出了。这时候靠 getchar() 或 pause 是没用的，得先用调试器跑一遍看断点停在哪、变量值是什么。
