静态库链接必须从左到右满足依赖方向：若liba.a依赖libb.a，则必须写为-la -lb，因链接器单向扫描，仅用后续库解析当前未定义符号；顺序错误将导致undefined reference错误。
静态库链接顺序必须从左到右满足依赖方向
链接器（ld）处理静态库是单向、一次性的：它按命令行从左到右扫描，对每个 .a 文件，只解析**当前已知未定义符号**，一旦某个库被读过，就不会回头再查。所以若 libA.a 用到了 libB.a 中的函数，libA.a 必须出现在 libB.a 左边——否则 libA.a 被处理时，libB.a 还没看到，符号就永远 unresolved。
常见错误现象：undefined reference to 'xxx'，尤其在 libA.a 明确 #include 了 libB.h 且调用了其函数时仍报错，八成是顺序反了。
-
g++ main.o -lA -lB✅ 正确（A 依赖 B） -
g++ main.o -lB -lA❌ 错误（B 先被扫，A 后扫但找不到 B 的符号） - 依赖链越长，顺序越关键：A → B → C → D，必须写成
-lA -lB -lC -lD
CMake 中 target_link_libraries 怎么写才不踩坑
target_link_libraries 默认行为和命令行一致：库列表从左到右传递给链接器，不自动重排。所以你不能指望 CMake “聪明地” 推导依赖顺序。
容易被忽略的一点：CMake 不会检查 .a 文件内部依赖，也不会报“顺序警告”，它只是忠实地把参数传给 ld。等到链接失败，才暴露问题。
- 手动排好序是最稳妥的：
target_link_libraries(myapp PRIVATE libA.a libB.a libC.a) - 如果依赖关系复杂或易变（比如 CI 中频繁增删库），直接用
--start-group/--end-group更省心： target_link_libraries(myapp PRIVATE -Wl,--start-group libC.a libA.a libB.a -Wl,--end-group)- 注意：
-Wl,--start-group和-Wl,--end-group是链接器选项，必须用-Wl,前缀透传，不能漏掉逗号
为什么 --start-group 能绕过顺序限制
--start-group 和 --end-group 不是“忽略顺序”，而是让链接器在组内**反复扫描多次**，直到所有符号都解析完毕。相当于把“一次左→右”变成“多轮左→右”，直到收敛。
它代价略高（链接时间稍长），但在以下场景值得用：
- 多个静态库存在循环依赖（A ←→ B）
- 第三方静态库依赖关系不透明，你不敢轻易调整顺序
- 构建脚本要兼容多个版本的 SDK，各版本库依赖顺序可能不同
- 团队协作中，有人加了个新
.a却没同步更新链接顺序，用 group 可避免连锁 break
命令行等价写法：g++ main.o -Wl,--start-group libX.a libY.a libZ.a -Wl,--end-group
混链动态库和静态库时顺序怎么定
动态库（.so）本身没有链接顺序要求——因为运行时才解析符号；但当你同时链接 .so 和 .a，顺序依然重要：静态库必须放在它所服务的动态库**右边**。
原因：链接器先处理 .so，它只记录需要哪些符号，不立即解析；然后遇到 .a，才去填这些“空缺”。如果 .a 放左边，它被扫完就过了，后面 .so 提出的符号没人认。
- 正确：
g++ main.o -lmylogic.so -lhelper.a -lpthread - 错误：
g++ main.o -lhelper.a -lmylogic.so（mylogic.so里未定义的符号可能无法被helper.a补上） - 更安全的做法：把所有静态库塞进
--start-group，动态库放外面，例如：-lmylogic.so -Wl,--start-group libhelper.a libbase.a -Wl,--end-group -lpthread
真正容易被忽略的是：即使你只链接一个静态库，只要它被某个动态库间接依赖，就必须确保它出现在该动态库之后——这个约束比纯静态链接更隐蔽，调试时容易绕远路。
