tasks.json中command写绝对路径易出错，因换环境需重配且可能因DLL缺失报错；应优先用"command":"gcc"依赖系统PATH，前提是终端能执行gcc --version。
为什么 tasks.json 里 "command" 写绝对路径反而容易出错
直接写 "C:/mingw64/bin/gcc.exe" 看似稳妥，但一旦换机器、重装 MinGW 或迁移到 WSL，所有构建任务就全挂；更隐蔽的问题是：VSCode 在调用时若未继承系统 PATH，即使路径存在也可能因缺失依赖库（如 libgcc_s_seh-1.dll）而报“找不到指定模块”。
- 优先用
"command": "gcc"，靠系统PATH解析——前提是gcc --version在终端能正常执行 - 若必须用绝对路径，确保该路径下所有 DLL 都可被加载（常需把
C:mingw64in加入系统环境变量，而不仅是用户变量） - Windows 上路径分隔符统一用正斜杠
/或双反斜杠\，单反斜杠会被 JSON 解析为转义字符，导致路径截断
launch.json 中 "program" 路径必须是相对于 workspaceFolder 吗
不是必须，但强烈建议。VSCode 调试器启动时工作目录默认为 ${workspaceFolder}，如果 "program" 写成 "./build/main.exe"，实际找的是 ${workspaceFolder}/build/main.exe；而写成 "build/main.exe"（无前导 ./）在某些旧版插件中可能解析失败。
- 始终用
${fileDirname}/${fileBasenameNoExtension}.exe这类变量组合，避免硬编码 - 多文件项目务必确认
"program"指向的是最终生成的可执行文件，不是中间.o文件 - Linux/macOS 下注意扩展名：可执行文件无
.exe，写成"${fileDirname}/${fileBasenameNoExtension}"
调试时提示 “Unable to start GDB: spawn …gdb.exe ENOENT” 怎么快速定位
这不是 VSCode 的问题，而是 launch.json 里 "miDebuggerPath" 指向了不存在的 gdb.exe，或系统根本没装 GDB。
- 先在终端运行
gdb --version，确认命令可用且版本 ≥ 8.0 - 检查
launch.json中"miDebuggerPath"是否与gcc同源（MinGW-w64 的gdb.exe必须和gcc.exe在同一bin目录） - Windows 上常见错误：装了 TDM-GCC 却在
c_cpp_properties.json里配了 MinGW 路径，结果gdb找不到 - VSCode 默认不校验
miDebuggerPath是否真实存在，只到调试时才报错，所以配置后务必手动验证路径
为什么改了 c_cpp_properties.json 里的 "compilerPath"，IntelliSense 还是标红 stdio.h
IntelliSense 不依赖编译器路径能否执行，而依赖它能否解析出标准头文件位置。仅设 "compilerPath": "gcc" 不够，必须让 VSCode 知道 GCC 的 sysroot 路径。
立即学习“C语言免费学习笔记（深入）”；
- Windows + MinGW-w64：确保
"intelliSenseMode"是"gcc-x64"（不是"msvc-x64"），且"includePath"包含"C:/mingw64/x86_64-w64-mingw32/include/**" - Ubuntu：
"compilerPath"设为"/usr/bin/gcc"后，VSCode 通常能自动推导includePath；若失败，手动加"/usr/include/**" - 修改后必须重启 VSCode 或点击右下角 C/C++ 图标 → “Reset IntelliSense Database”，否则缓存会掩盖改动
gcc、gdb、IntelliSense 三者必须来自同一发行版，混用不同来源的二进制几乎必然触发头文件找不到、调试器崩溃或符号无法加载。 
