VSCode需手动配置tasks.json和launch.json才能正确编译调试C/C++程序；仅安装Microsoft官方C/C++扩展，禁用Code Runner等黑盒插件；确保gcc/gdb在PATH中且版本可用；tasks.json须含"problemMatcher": ["$gcc"]以支持错误跳转；launch.json的"program"必须指向带-g生成的可执行文件；修改c_cpp_properties.json后须手动“重新扫描”。
VSCode 本身不带 C/C++ 编译器或调试器，装完插件不配好 tasks.json 和 launch.json，写完 main.c 点运行大概率报错：“终端将被任务重用，按任意键关闭。”——这不是 VSCode 的问题，是没告诉它“怎么编译”“怎么运行”。
装对插件：C/C++ 扩展 ≠ C++ 插件全家桶
只装 Microsoft 官方的 C/C++（ID：ms-vscode.cpptools）就够了。别装 C/C++ Runner 或 Code Runner 这类“一键运行”插件——它们绕过 tasks.json，编译参数黑盒化，出错时连 gcc -o 漏了哪个 -I 都查不到。
-
C/C++提供智能提示、跳转、clangd支持（需手动启用）、以及真正可配置的构建/调试链路 - 如果用 MinGW-w64，确认
gcc、gdb已加进系统 PATH，且在终端里能直接敲gcc --version返回版本号 - Linux/macOS 用户别依赖 Xcode 命令行工具自带的
clang——它默认不带libstdc++，C++17std::filesystem会链接失败；建议显式安装g++并在c_cpp_properties.json里指定"compilerPath": "/usr/bin/g++"
tasks.json 必须手写：别信“自动检测”
VSCode 不会猜你用 gcc 还是 clang，也不会自动加 -std=c17 或包含第三方头文件路径。靠“运行生成任务”弹窗选出来的 tasks.json 往往缺关键字段，比如漏掉 "group": "build"，导致 Ctrl+Shift+B 不生效。
一个最小可用的 C 编译任务示例（保存为 .vscode/tasks.json）：
立即学习“C++免费学习笔记（深入）”；
{
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "gcc build",
"command": "gcc",
"args": [
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}",
"-std=c17"
],
"group": "build",
"problemMatcher": ["$gcc"]
}
]
}
-
"problemMatcher": ["$gcc"]是关键——它让编译错误能双击跳转到对应行；没这行，报错就纯文本堆在终端里 -
${file}是当前打开的文件，不是整个项目；多文件工程必须改用Makefile或cmake，硬塞一堆args维护成本爆炸 - Windows 下用 MinGW，
command写"gcc"即可；WSL 中若用 Ubuntu 的gcc，确保tasks.json的"type"设为"shell"而非"process"，否则 WSL 路径映射会出错
launch.json 调试前先确认 gdb/lldb 可执行
点绿色 ▶ 启动调试却卡在 “正在启动调试适配器…”？八成是 gdb 路径不对，或者二进制没带调试符号（-g 丢了）。
- 先在终端里手动运行一遍编译命令，再敲
./a.out确认能跑；再敲gdb ./a.out看是否进入调试器界面——连这个都不行，launch.json再准也没用 -
launch.json中"program"字段必须指向带调试信息的可执行文件（即tasks.json里-o输出的路径），不能写"${file}" - MinGW 用户注意：
gdb.exe和gcc.exe必须来自同一套 MinGW 发行版（如 x86_64-13.1.0-release-posix-seh），混用会导致断点失效或Cannot find bounds of current function
最常被跳过的一步：每次改完 c_cpp_properties.json（比如加了 "includePath"），必须点右下角的 “C/C++ 配置” → “重新扫描”，否则 #include 报红不会消失。这个动作没有自动触发机制，也无提示。
