根本原因是C++编译器对函数名进行名称修饰，而C静态库导出的是未经修饰的原始符号名；解决方法是在头文件中用extern "C"包裹声明，使C++按C链接规则处理符号。
clang++ 链接静态库时为什么报 undefined reference
根本原因不是库没找到，而是链接顺序错、符号没导出、或库本身没包含定义。静态库是被动提取的——链接器只从 .a 里拉它认为“需要”的符号，且严格按命令行从左到右扫描。
-
clang++ main.o -L. -lmylib✅ 正确：目标文件在前，库在后，链接器能推导依赖 -
clang++ -L. -lmylib main.o❌ 失效：库提前扫过，main.o 里的未定义符号已“错过”匹配机会 - 用
nm -C libmylib.a确认符号是否在T段（已定义）；若只在U段，说明该函数根本没编译进.o - 类模板/inline 函数若没显式实例化，不会生成符号——哪怕头文件里写了实现，也进不了
.a
怎么让 clang++ 强制链接静态库而不是动态库
默认情况下 -lfoo 会优先找 libfoo.so，即使 libfoo.a 存在。这不是 bug，是设计行为。
- 最可靠方式：
clang++ main.o /path/to/libfoo.a -o app—— 直接传.a文件路径，绕过搜索逻辑 - 用链接器指令控制模式：
clang++ main.o -Wl,-Bstatic -lfoo -Wl,-Bdynamic -o app，其中-Bstatic开启静态链接段 - 如果
libfoo.a在非标准路径，-L/path必须紧挨着-lfoo前面，不能写成-lfoo -L/path - 注意：macOS 上
-Wl,-Bstatic无效，只能靠绝对路径或-force_load
CMake 里用 Clang 构建静态库最容易漏的三件事
配置看起来跑通了，但下游项目一用就报 xlog.h: No such file or directory 或链接失败，基本就是这三项之一没做。
-
add_library(xlog STATIC xlog.cpp)必须显式写STATIC—— 如果全局设了-DBUILD_SHARED_LIBS=ON，不写就变成.so -
target_include_directories(xlog PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)必须用PUBLIC，否则调用方#include "xlog.h"找不到头文件 -
add_library必须出现在add_executable之前，且target_link_libraries(test_xlog PRIVATE xlog)的xlog名必须和库目标名完全一致（大小写敏感）
macOS 上 clang++ 链接静态库的特殊坑
Linux 和 macOS 表面命令一样，底层行为差异大，尤其涉及路径和符号解析。
-
ar在 macOS 默认不生成索引，必须跟ranlib libfoo.a补上，否则链接时找不到符号 -
-rpath对静态库无效，但如果你混用了动态依赖，-Wl,-rpath,@loader_path/../lib要加单引号防 shell 展开 - 检查是否真注入了 rpath：
otool -l ./app | grep -A2 LC_RPATH；查 dylib ID：otool -D libxxx.dylib，不匹配就得用install_name_tool -id "@rpath/libxxx.dylib" libxxx.dylib - Clang on macOS 默认用
ld64，某些旧版本不支持-Bstatic，别试
实际构建中，最难 debug 的永远不是“库没编译”，而是“库编译了，但没导出你需要的那个符号”——动手前先 ar -t libxxx.a 看文件列表，再 nm -C libxxx.a | grep YourSymbol 确认存在且已定义。
