最可靠方式是用ar解包再重打包：先ar -x提取所有.o文件，处理重复和-fPIC问题，再ar rcs重建新.a库；CMake的target_link_libraries不能合并静态库。
直接用 ar 解包再重打包是最可靠、最可控的方式，没有替代方案能绕过这一步。CMake 的 target_link_libraries 不会自动合并静态库内容，它只是记录链接顺序；所谓“自动合并”其实是链接器在最终可执行文件阶段才做的符号提取，不是生成新 .a 文件。
为什么不能直接 ar -q libnew.a liba.a libb.a
因为 ar 把整个 .a 文件当做一个普通成员塞进去，不是解压它里面的目标文件（.o）。结果是新库里存的是两个嵌套的归档，链接器无法识别内部符号，报错类似：undefined reference to 'xxx'，哪怕源函数明明在 libb.a 里。
必须先拆开，拿到原始 .o 文件，再统一归档。
-
ar -x liba.a会把所有.o提取到当前目录（注意：不创建子目录） - 多个库若有同名
.o（比如都叫utils.o），后解压的会覆盖前一个 —— 这是静默行为，极易漏检 - 若原始
.o编译时没加-fPIC，合并后用于构建共享库会失败，错误如：relocation R_X86_64_32 against symbol
正确合并流程：解包 → 去重 → 归档
核心就三步：解压所有 .a 到临时目录、检查并处理重复目标文件、用 ar rcs 重建。
立即学习“C++免费学习笔记（深入）”；
- 建临时目录：
mkdir -p tmp_merge && cd tmp_merge - 逐个解包：
ar x ../liba.a && ar x ../libb.a && ar x ../libc.a - 检查重复：
ls *.o | sort | uniq -d—— 有输出就得人工确认是否真能合并（比如同名但实现不同） - 归档：
ar rcs ../liball.a *.o（注意路径，../是为了把结果放回原位置） - 清理：
cd .. && rm -rf tmp_merge
别省略 s 参数（ar rcs），否则链接器找不到符号索引，报 library not found for -lxxx 或静默跳过某些符号。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
用 Makefile 自动化合并（适合 CI/部署场景）
如果每次都要手动敲命令，容易出错。一个最小可行的 Makefile 片段：
LIBS := liba.a libb.a libc.a TARGET := liball.a $(TARGET): $(LIBS) mkdir -p .merge_tmp cd .merge_tmp && \ for l in $(LIBS); do ar x ../$$l; done && \ ar rcs ../$@ *.o && \ cd .. && rm -rf .merge_tmp .PHONY: clean clean: rm -f $(TARGET) .merge_tmp
运行 make 就生成 liball.a；make clean 清理中间产物。注意 for l in ... 必须写在同一行且用反斜杠续行，否则 shell 会在子 shell 中执行，cd .merge_tmp 失效。
常见坑：CMake 里 target_link_libraries 不等于合并静态库
很多人误以为这样就能产出一个合并后的 .a：
add_library(mylib STATIC IMPORTED) set_property(TARGET mylib PROPERTY IMPORTED_LOCATION liball.a) target_link_libraries(app PRIVATE mylib a b c)
这只是让 app 链接 mylib 和 a/b/c，完全没改变 liball.a 的内容。真正要发布单个静态库给下游，必须走前面的 ar 手动流程。
另外，如果你的静态库依赖其他静态库（比如 libb.a 用了 liba.a 的符号），仅把 libb.a 加进合并步骤是不够的——你得确保 liba.a 也参与解包，否则链接时仍缺符号。
