Clang报“file not found”本质是编译阶段头文件路径未配置，与静态库无关；需用-I指定头文件搜索路径，而非-l或-L，且clang、clangd、clang-tidy路径配置相互独立。
Clang 链接静态库时“找不到头文件”，本质不是链接问题，而是编译阶段（预处理/解析）就失败了——clang 根本没找到 #include 的头文件路径，压根走不到链接那步。
为什么 clang 编译时会报 “file not found” 却和静态库无关
静态库（如 libfoo.a）只含目标代码，不包含头文件。头文件缺失发生在 clang 解析源码、做语法检查和生成 AST 时，跟 -lfoo 或 -L/path 完全无关。
常见误操作是：以为加了 -lmylib 就自动带入头文件路径，其实不会。头文件搜索和链接是两个独立阶段。
- 报错位置总在
#include <xxx>行，而不是undefined reference -
clang -v main.cpp输出里会显示#include <> search starts here:，但你想要的路径不在其中 - 即使删掉所有
-l参数，错误照旧出现
clang 编译 C++ 时怎么指定标准库头文件路径
Linux/macOS 上 clang 默认不自带完整 C++ 头文件，它依赖系统 GCC 或 LLVM 提供的 libstdc++ 或 libc++。路径必须显式告诉它。
- 先确认你用的是哪个标准库：
clang++ -dumpversion和g++ -dumpfullversion对比；或看clang++ -v输出里 “Selected GCC installation” - 查出对应 GCC 版本的头文件位置，例如：
/usr/lib/gcc/x86_64-linux-gnu/12/include/c++ - 用
-I添加（注意是-I，不是-l）：clang++ -I/usr/lib/gcc/x86_64-linux-gnu/12/include/c++ main.cpp - 若用 libc++，需装
libc++-dev包，并加-I/usr/include/c++/v1（macOS 路径常为/Applications/Xcode.app/.../include/c++/v1）
clangd / VSCode 里头文件标红，但命令行 clang 能编译成功
这是编辑器插件没复用你的 shell 环境或构建配置，clangd 自己瞎猜路径导致的。
- 最可靠方式：生成
compile_commands.json（用 CMake 加-DCMAKE_EXPORT_COMPILE_COMMANDS=ON，或用bear --make），clangd 会自动读取其中的-I参数 - 手动配置 clangd 启动参数，在 VSCode 的
settings.json中加："clangd.arguments": ["--query-driver=/usr/bin/clang++"]，让 clangd 去调用真实编译器反推 include 路径 - 避免在
c_cpp_properties.json里硬写死路径，尤其别漏掉/usr/include/x86_64-linux-gnu/c++/12这类架构子目录 - 如果用了交叉工具链，
--query-driver必须指向那个工具链下的clang++，否则路径全错
clang-tidy 报 “file not found” 怎么修
clang-tidy 是基于 clang 的静态分析器，但它默认不继承构建系统的 include 路径，容易漏掉。
- 必须显式传
--分隔符，后面跟编译参数：clang-tidy foo.cpp -- -x c++ -I/usr/include/c++/12 -
-x c++很关键，否则它可能当 C 文件处理，跳过 C++ 标准库路径 - 多个路径用多个
-I：-I/path1 -I/path2，不能写成-I/path1:/path2 - 若项目用 CMake + Ninja，推荐直接运行
clang-tidy -p build/ foo.cpp，它会从build/compile_commands.json自动加载所有参数
真正麻烦的不是路径本身，而是 clang 不同组件（clang、clangd、clang-tidy）各自维护一套路径发现逻辑，且互不共享。一个地方配好了，不代表另一个地方也生效——得挨个验证输出里的 search starts here: 行。
