静态库复用需分离存放头文件与库文件、统一规划include/lib/bin目录、显式指定-I和-L路径、确保ABI兼容、验证导出符号。
静态库文件和头文件必须分离存放
直接把 libxxx.a 和头文件混在项目源码里，下次换项目就得重新复制、改路径、调编译命令——这是最常见也最累人的错误。静态库复用的前提是「接口稳定、位置固定、路径可配置」。
正确做法是统一规划三个目录：
-
include/：只放对外公开的头文件（如math_utils.h），不放实现或私有头 -
lib/：只放编译好的libxxx.a，不放 .o 或源码 -
bin/或其他目录：放最终生成的可执行文件，与库完全解耦
比如你把 libmathutils.a 放在 /opt/mylibs/lib/，对应头文件放在 /opt/mylibs/include/，所有项目都按这个路径引用，就不用每次改 -I 和 -L。
链接时必须显式指定库路径和库名
很多人以为把 libxxx.a 放进当前目录，写 gcc main.c -lxxx 就能链接成功——错。GCC 默认只查系统路径（/usr/lib、/usr/local/lib），不会自动扫当前目录。
必须同时提供两件事：
-
-I/opt/mylibs/include：让预处理器能找到#include "xxx.h" -
-L/opt/mylibs/lib -lxxx：让链接器在指定路径下找libxxx.a
注意：-L 和 -l 顺序不能颠倒；-lxxx 中的 xxx 是库名（去掉 lib 前缀和 .a 后缀），不是文件名。
跨项目复用时最容易踩的 ABI 兼容坑
你在项目 A 用 g++-11 -std=c++17 编的 libxxx.a，项目 B 用 clang-16 -std=c++20 去链接，大概率报 undefined reference ——不是路径问题，是 ABI 不兼容。
关键点：
- 静态库的 ABI 取决于编译它的编译器版本、标准、ABI 标志（如
-fPIC虽然对静态库非必需，但若后续想转动态库就受限） - 不同 STL 实现（libstdc++ vs libc++）之间无法混用
- C++ 项目尤其要注意：
-std=必须一致，否则名字修饰（name mangling）规则不同，符号根本对不上
建议：给静态库加构建标记，比如在 libxxx.a 所在目录放个 BUILD_INFO 文件，记录 g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 和 -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=1。
用 nm -g --defined-only libxxx.a 验证导出符号
你以为头文件里声明了 int add(int, int)，链接时就一定能用？不一定。如果源码里忘了实现，或者函数被 static 修饰，或者编译时加了 -fvisibility=hidden，它就不会出现在静态库的导出符号表里。
每次发布新版本静态库前，务必运行：
nm -g --defined-only libmathutils.a | grep add
看到类似 0000000000000000 T _Z3addii（C++ mangled 名）或 0000000000000000 T add（C 风格）才算真正导出了。没输出 = 项目里调用会失败，且错误只在链接时报，不编译。
这个检查比“能编译通过”更接近真实可用性，别跳过。
