ar 不认 -I 或 include 路径，因为它是纯归档工具，仅打包已编译的 .o 文件，不参与预处理或头文件解析；所有 #include 查找、宏展开均由 clang -c 阶段通过 -I 参数完成，顺序决定搜索优先级，且 #include "x.h" 与 #include <x.h> 的查找路径逻辑不同。
Clang 生成静态库时，include 路径不参与“生成”过程本身，只影响编译源文件阶段；你得在编译 .c/.cpp 为 .o 时用 -I 指定，而不是在 ar 打包阶段配置。
为什么 ar 不认 -I 或 include 路径
ar 是归档工具，只负责把已编译好的 .o 文件打包成 .a，它完全不处理头文件或预处理逻辑。所有 #include 解析、宏展开、路径查找，都发生在前面的 clang -c 阶段。
- 错误做法：
ar rcs libfoo.a -I/path/to/include foo.o→ar会把-I/path/to/include当作一个要归档的“文件”，报错找不到 - 正确顺序：先用
clang -I/path/to/include -c foo.c -o foo.o，再ar rcs libfoo.a foo.o - 如果你漏了
-I导致foo.c编译失败，根本不会有foo.o，自然也打不了包
Clang 编译源码进 .o 时怎么传 include 路径
关键就是 clang -c 命令里的 -I 参数，支持多个、可重复使用，顺序决定搜索优先级（靠前的路径优先匹配）：
clang -I./include -I/usr/local/mylib/include -c foo.c -o foo.o- 若
foo.c中写的是#include "utils.h"，Clang 先查./include/utils.h，再查/usr/local/mylib/include/utils.h - 如果用的是
#include <mylib></mylib>，则只在这些-I路径 + 系统默认路径（如/usr/include）里找，不查当前目录 - 路径含空格？必须加引号：
-I"/path/with space/include"
CMake 项目里怎么统一管理 include 路径
手动敲 clang -I 容易漏、难维护。CMake 会帮你把 include_directories() 或更推荐的 target_include_directories() 转成对应编译参数：
add_library(mylib STATIC foo.cpp bar.cpp)-
target_include_directories(mylib PUBLIC ./include)→ 所有链接mylib的目标，都能自动获得-I./include -
target_include_directories(mylib PRIVATE /opt/thirdparty/include)→ 仅mylib自己编译时用，不透出给依赖者 - 别用全局的
include_directories()，它会让所有后续 target 都带上这个路径，容易污染和冲突
容易被忽略的路径语义细节
#include 写法不同，-I 路径是否生效也不同：
-
#include "local.h"：先查源文件所在目录，再按-I顺序查，最后系统路径 -
#include <system.h></system.h>：跳过源文件所在目录，只按-I顺序 + 系统路径查 - 所以即使你加了
-I./inc，#include "inc/local.h"仍可能失败——因为 Clang 会先去当前目录找inc/local.h，而不是去./inc下找；正确写法是#include "local.h"并确保-I./inc存在 - 路径拼接是纯字符串行为，没有自动补斜杠，
-I./inc和-I./inc/对 Clang 来说等价，但对人读起来后者更明确
