动态库编译时头文件应放在gcc能搜索到的路径中，关键是在编译源码（如add.c）时让#include成功定位：推荐与源文件同目录，或用-i显式指定父目录；-i路径按命令行顺序查找，不可省略空格；环境变量c_include_path/cplus_include_path仅在未用-nostdinc时生效；公共头文件需单独提供给调用方，不打包进.so。
动态库编译时头文件放哪才被 gcc 找到
头文件本身不参与动态库的二进制生成，但必须能让 gcc 在编译源码（如 add.c）时成功解析声明。所以关键不是“动态库里放头文件”，而是“编译动态库的源文件时，#include 能顺利定位到头文件”。
常见错误现象：gcc -shared -fpic add.c -o libfoo.so 报错 fatal error: foo.h: No such file or directory —— 这说明 add.c 里写了 #include "foo.h" 或 #include <foo.h></foo.h>，但 gcc 没搜到。
-
#include "foo.h"：先查当前目录（即add.c所在目录），再查-I指定路径，最后查系统默认路径 -
#include <foo.h></foo.h>：跳过当前目录，只查-I和系统默认路径（含/usr/include等） - 推荐做法：把
foo.h和add.c放同一目录，或用-I ./inc显式指定头文件所在目录 - 别把头文件塞进
.so文件里——动态库只含编译后的机器码，不打包头文件
-I 参数位置和多个路径的顺序影响实际查找结果
-I 的生效顺序严格按命令行出现顺序，而非字母或路径深浅。比如 gcc -I /opt/mylib/include -I ./inc -shared -fpic add.c -o libfoo.so，gcc 会先去 /opt/mylib/include 找，找不到再去 ./inc，最后才系统路径。
- 路径可以是相对路径（如
-I ../headers）、绝对路径（如-I /usr/local/include/myproj），甚至空目录（-I ""表示当前目录） - 避免写成
gcc -I./inc（中间没空格）——这会被当作一个参数名，gcc报错unrecognized command-line option '-I./inc' - 如果头文件依赖嵌套包含（如
foo.h里#include "utils/bar.h"），确保-I指向的是utils/的父目录，而不是utils/本身
头文件路径设成环境变量后，gcc 仍可能不生效
设置 C_INCLUDE_PATH 或 CPLUS_INCLUDE_PATH 后，gcc 确实会在命令行 -I 之后、系统路径之前搜索这些目录。但容易忽略两点：
- 环境变量只对当前 shell 会话有效，新开终端需重新
source ~/.bashrc或手动export -
C_INCLUDE_PATH仅影响 C 文件；C++ 源码（.cpp）必须用CPLUS_INCLUDE_PATH，否则无效 - 若同时用了
-nostdinc，则C_INCLUDE_PATH也会被跳过——这个参数会彻底关闭所有默认路径（含环境变量路径），只认-I - 验证是否生效：加
-v参数运行gcc -v -shared -fpic add.c -o libfoo.so，输出里会列出所有搜索路径，一眼就能确认你的-I或环境变量是否被读入
动态库使用者需要的头文件 ≠ 动态库编译时用的头文件
这是最容易混淆的一点：你编译 libfoo.so 时用的 foo.h 是给 add.c 看的；而别人链接这个库时写的 #include "foo.h"，需要的是另一份——用于声明导出函数接口的“公共头文件”。
- 这份公共头文件通常要单独安装到系统路径（如
/usr/include/foo.h）或用户指定路径（如/opt/foo/include/foo.h），并配-I /opt/foo/include - 它内容应精简：只含
extern函数声明、宏定义、结构体，不含实现细节或私有头文件包含 - 如果忘了提供这份头文件，调用方编译时就会报
unknown type name 'foo_t'或implicit declaration of function 'foo_init' - 不要把内部实现头文件（如
internal.h）暴露给使用者——它们只该出现在libfoo.so编译阶段，不该出现在安装路径里
" " 和 .so 文件里该带头文件——这些才是线上构建失败的高频原因。
