c_cpp_properties.json必须按工作区配置，因为不同C++项目编译器、标准库路径和宏定义差异极大，全局配置会导致IntelliSense报“找不到vector”或跳转错误；例如嵌入式裸机（-nostdinc++）与Qt桌面应用的includePath和defines完全冲突。
为什么 c_cpp_properties.json 必须按工作区配置，而不是全局？
因为 C++ 项目之间编译器、标准库路径、宏定义差异极大，全局配置会强制所有项目共享同一套头文件路径和编译器行为，导致 IntelliSense 报错“找不到 vector”或跳转到错误的 STL 实现。比如你在写嵌入式裸机代码时用了 -nostdinc++，而另一个项目是 Qt 桌面应用，两者 includePath 和 defines 完全冲突。
实操建议：
- 永远通过命令面板运行
C/C++: Edit Configurations (UI)，再点右上角“切换为 JSON 编辑”，确保生成的是.vscode/c_cpp_properties.json（不是用户级配置） -
name字段必须唯一且可读，例如"Linux-Clang-16-C++20"，方便后续在状态栏快速切换 - 不要手动写死系统路径如
/usr/include/c++/11；优先用${env:HOME}或${vcpkgRoot}变量，配合compilerPath让插件自动推导标准库路径
CMake Tools 插件如何让 IntelliSense 精准到函数参数级？
它本身不提供补全，但会把 CMake 生成的 compile_commands.json 自动喂给 C/C++ 插件。后者据此获知每个源文件实际使用的编译器、-I、-D、甚至 -std=c++20，从而启用对应语言特性的语义分析。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 装了
CMake Tools却没效果 → 检查项目根目录是否有CMakeLists.txt，且已执行过CMake: Configure - 跳转定义跳到系统头文件而非你本地的重载版本 → 确认
compile_commands.json中该文件的command字段包含你的项目include路径，而非仅系统路径 - 修改
CMakeLists.txt后补全延迟或失效 → 手动触发CMake: Build或CMake: Clean and Rebuild，强制刷新数据库
为什么 Code Runner 不适合调试，但能救急编译单文件？
它本质是调用 shell 命令跑 g++ -o a.out main.cpp，不生成 .debug 信息，也不写入 launch.json 所需的调试符号。但它对学习阶段写 hello.cpp 这类单文件、无依赖的小练习极其高效。
使用场景与限制：
- 适合：算法题、语法验证、快速原型验证
- 不适合：含
#include "my_header.h"的多文件项目、需要断点调试、依赖第三方库（如 Boost） - 关键配置项：
code-runner.runInTerminal必须设为true，否则交互式输入（如cin >> x）直接失败 - 若要支持 C++17，需改
code-runner.executorMap中的cpp条目，把-std=c++14换成-std=c++17
调试失败时，launch.json 最容易漏掉哪三个字段？
不是 program 或 miDebuggerPath，而是这三个隐性但致命的配置：
-
externalConsole：Windows 下不设为true，控制台窗口一闪即逝，cin类输入完全不可用 -
MIMode：用 MinGW 调试必须显式写"MIMode": "gdb"，否则默认尝试lldb导致连接失败 -
setupCommands中的enable-pretty-printing：不开启会导致std::vector在监视窗口只显示内存地址，无法展开查看元素
复杂点在于，这些字段的生效依赖于 type（如 cppdbg）和底层调试器能力。比如 macOS 上用 lldb 就不需要 MIMode，但必须配 preLaunchTask 确保构建产物最新——这点常被忽略，结果调试的是旧二进制。
