clang不生成静态库，cmake才是关键：需用add_library(... static)定义静态库，启用cmake_export_compile_commands on生成compile_commands.json，并配置clangd的--compile-commands-dir指向构建目录。
Clang本身不生成静态库，CMake才是关键
Clang只是编译器，它负责把 .cpp 编译成 .o，但“打包成 libxxx.a”这件事必须由构建系统完成——CMake 是最常用、最可靠的选择。直接调用 clang++ -c 手动编译再用 ar 打包虽然可行，但无法管理依赖、头文件路径、标准版本等，极易出错，也不可持续。
CMakeLists.txt 必须启用 CMAKE_EXPORT_COMPILE_COMMANDS
clangd 要正常工作（跳转、补全、clang-tidy 检查），必须让 CMake 生成 compile_commands.json。这个文件是 clangd 的唯一索引依据，缺了它，所有智能功能都会退化成纯文本匹配。
-
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)必须放在project()之后、任何add_library()或add_executable()之前 - 不要写成
set(CMAKE_EXPORT_COMPILE_COMMANDS TRUE)—— CMake 只认ON/OFF字符串 - 生成的
compile_commands.json默认在构建目录（如build/）下，不是项目根目录
用 add_library(... STATIC) 定义静态库目标
这是 CMake 声明静态库的唯一标准方式。clangd 不关心你用的是 Clang 还是 GCC，它只解析 CMake 生成的编译命令；而链接阶段是否能正确找到符号，取决于你是否在可执行目标中通过 target_link_libraries() 显式关联该库。
- 示例片段：
cmake_minimum_required(VERSION 3.10) project(MyLib) <p>set(CMAKE_CXX_STANDARD 17) set(CMAKE_EXPORT_COMPILE_COMMANDS ON)</p><h1>声明静态库：源文件在 src/ 下</h1><p>add_library(my_static_lib STATIC src/utils.cpp src/logger.cpp )</p><h1>可选：导出头文件路径，供其他 target 使用</h1><p>target_include_directories(my_static_lib PUBLIC include)</p><h1>若有可执行目标，需显式链接</h1><p>add_executable(app main.cpp) target_link_libraries(app PRIVATE my_static_lib)</p>
-
STATIC关键字不能省略，否则默认是SHARED -
PUBLIC和PRIVATE控制头文件可见性，影响下游 target 的#include路径解析，clangd 会据此提供准确补全 - 生成的静态库文件名是平台约定的：
libmy_static_lib.a（Linux/macOS）、my_static_lib.lib（Windows）
构建时别漏掉 --compile-commands-dir 配置
VS Code 的 clangd 插件默认只在项目根目录找 compile_commands.json，但 CMake 把它放在 build/ 下。如果不告诉 clangd 去哪读，它就只能做基础语法检查，没有跨文件跳转、重命名、clang-tidy 等核心能力。
- 在 VS Code 设置里加这一行（推荐）：
"clangd.arguments": ["--compile-commands-dir=build"]
- 或者用命令行启动 clangd（调试时有用）：
clangd --compile-commands-dir=build - 如果构建目录不是
build（比如叫out或build-debug），必须同步改这里，否则 clangd 会静默失败 - 路径是相对于 VS Code 工作区根目录的相对路径，不是绝对路径
最容易被忽略的是：即使 CMake 构建成功、libxxx.a 文件已生成，只要 clangd 没读到 compile_commands.json，你就等于在用记事本写 C++ —— 没有语义感知，所有“智能”都只是幻觉。
