禁用 microsoft c/c++ 扩展是第一步，因其与 clangd 冲突抢夺语言服务请求；clangd 依赖 compile_commands.json 实现精准跳转与补全，需确保正确生成并配置路径，且日志诊断不可忽略。
VSCode 插件和目录配置不是“装完就灵”的事，真正影响开发体验的是插件协同方式 + 工作区级配置的优先级控制。盲目堆插件、乱改 .vscode 文件，反而会让跳转失效、补全卡顿、构建失败。
为什么禁用 Microsoft C/C++ 扩展（cpptools）是 C++ 项目的第一步
它和 clangd 都提供语言服务，但默认会抢 textDocument/definition 请求，导致 goto definition 跳到头文件声明而非实现，hover 显示类型不完整，甚至 compile_commands.json 被忽略。
- 禁用后，
clangd成为唯一语言服务器，所有语义操作（rename、format on type、semantic highlighting）都基于真实编译参数 - 若项目用 CMake，
clangd会自动读取compile_commands.json；不用 CMake 则需手动配置clangd.fallbackFlags - Windows 上若仍用 MSVC 工具链，可保留 cpptools，但必须关闭其 IntelliSense 引擎：在
settings.json中设"C_Cpp.intelliSenseEngine": "disabled"
.vscode 目录里哪些文件真正在起作用
不是所有文件都会被加载，VSCode 按明确规则决定是否生效：
-
c_cpp_properties.json：仅当启用 cpptools 时才读取；clangd完全忽略它——别再往里面填includePath了 -
tasks.json：只影响终端执行Tasks: Run Task，不影响 clangd 行为；CMake 项目建议用CMake Tools自带构建，而非手写 task -
launch.json：调试器配置，与语言服务无关；GDB/LLDB 路径、miDebuggerPath错误会导致断点不命中 -
settings.json：工作区级设置，优先级高于用户设置；关键项如"clangd.arguments"必须在这里配，比如：["--log=error", "--pretty"]
插件路径冲突导致扩展不加载的真实原因
VSCode 启动时扫描 extensions 目录，但若多个插件注册相同激活事件（如 onLanguage:cpp），后加载的会覆盖前一个——不是“谁先装谁生效”，而是按文件夹字母序加载。
- 典型冲突：同时安装
ms-vscode.cmake-tools和旧版twxs.cmake，后者可能劫持cmake.configure命令 - 自定义插件路径（
code --extensions-dir /path）能隔离测试，但必须确保该路径下无重名插件，否则版本混乱 - 插件文件夹名含版本号（如
llvm-vs-code-extensions.vscode-clangd-0.15.0），升级后旧版残留会导致双实例竞争
CMake + clangd 组合下 compile_commands.json 生成失败的排查点
clangd 依赖这个文件获取每个源文件的完整编译命令（含宏定义、include 路径），生成失败 = 补全失效。
- 确保 CMake 构建时加
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON，不是仅靠cmake . - 构建目录不能是项目根目录；推荐
mkdir build && cd build && cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. - 如果用 Ninja，检查
build/ninja -t compdb是否能输出 JSON；不能则说明 CMakeLists.txt 中未启用export_compile_commands或构建系统未识别 - clangd 默认只读取项目根目录下的
compile_commands.json；若生成在build/下，需在settings.json中设"clangd.arguments": ["--compile-commands-dir=build"]
最常被忽略的其实是 clangd 的日志——开个终端运行 clangd --log=verbose，再在 VSCode 里触发一次跳转，看它实际读了哪个 compile_commands.json、是否报 Failed to load compilation database。没日志，就等于盲调。
