Clang编译动态库必须用-I显式指定头文件路径，否则#include失败；项目头文件建议用双引号，-I路径需随库分发，且CI中应参数化避免硬编码。
头文件路径必须用 -I 显式指定，不能靠默认搜索或相对包含
Clang 不会自动在当前目录或源文件同级目录里找头文件。哪怕 MyLibrary.h 和 MyLibrary.c 在同一个文件夹下，#include "MyLibrary.h" 也会编译失败——除非你告诉 Clang 去哪找。
常见错误现象：fatal error: 'MyLibrary.h' file not found，尤其在跨目录组织（如 include/ 和 src/ 分开）时高频出现。
-
-Iinclude是最常用写法，表示让预处理器去include/目录下搜#include <...>或#include "..." - 多个头文件目录？叠加多个
-I：比如-Iinclude -Ithird_party/headers - 路径是相对于执行
clang命令时的当前工作目录，不是相对于源文件位置 - 不要用
-I.代替明确路径——它会让整个当前目录进入头文件搜索范围，容易引发命名冲突或意外包含
#include 用尖括号还是双引号，影响实际查找顺序
这不只是风格问题，它直接决定 Clang 查找头文件的优先级和路径范围。
使用 #include <MyLibrary.h> 时，Clang 先查系统路径（/usr/include 等），再查 -I 指定的路径；而 #include "MyLibrary.h" 会先查当前源文件所在目录，再查 -I 路径，最后才查系统路径。
- 项目自有头文件建议统一用双引号：
#include "MyLibrary.h"，避免和系统头重名冲突 - 如果头文件放在
include/下，且你用了-Iinclude，那两种写法都能命中，但语义更清晰的是双引号 - 别混用：同一项目里有的写
<xxx.h>、有的写"xxx.h"，容易在迁移或 CI 环境中因路径差异突然报错
动态库分发时，头文件必须和 .dylib 一起提供
生成 libMyLibrary.dylib 只是完成了二进制部分；调用方要能编译通过，必须拿到对应的头文件，否则 add(1, 2) 这种调用连声明都看不到。
- 头文件不是“编译完就扔”的临时产物，它是接口契约，必须随动态库一同交付
- 典型分发结构：
mylib/lib/libMyLibrary.dylib+mylib/include/MyLibrary.h - 调用方需同时配置：
-I/path/to/mylib/include（找声明）+-L/path/to/mylib/lib（找符号实现） - macOS 上特别注意：
otool -D libMyLibrary.dylib查看 install name，如果它写的是绝对路径（如/usr/local/lib/libMyLibrary.dylib），而你实际放到了别的位置，即使头文件对了，链接时也可能静默失败
Clang 编译动态库命令里，-I 和 -dynamiclib 的位置无关，但必须存在
不像 -L 和 -l 那样有严格顺序依赖，-I 放前放后都行，但它不能漏。
正确示例：clang -dynamiclib -o libMyLibrary.dylib src/MyLibrary.c -Iinclude
错误示例：clang -dynamiclib -o libMyLibrary.dylib src/MyLibrary.c（没 -I，头文件找不到）
- 即使源文件里没
#include，比如纯汇编或裸 C 函数，也建议保留-I——为未来扩展留余地 - CI 或多平台构建时，建议把
-I路径写成变量或参数化，避免硬编码路径导致本地能过、服务器失败 - 头文件里如果有
#include <stdio.h>这类标准头，-I不影响它们，Clang 会自动处理系统头路径
.dylib 本身，而在 -I 漏了、路径错了、或者头文件没随库一起给出去。 
