C++项目中间库依赖应当如何处理？有哪些常见行业实践？

针对你描述的「依赖含内部专属库、需固定boost等第三方库版本、全量编译耗时高」的场景，C++工业界的通用实践是对方案2做自动化优化落地，三个可选方案的优劣势和适配场景如下：

现有方案评估 #

• 方案1（git submodule管理源码、全量编译）：仅适合依赖迭代极频繁、编译成本低的小型项目。你的场景下全量编译耗时过长，会严重拉低CI和本地开发效率，不建议作为长期方案。如果团队规模极小、暂时不想做额外配置，可以搭配ccache/sccache编译缓存工具使用，只要依赖版本无变动，后续编译可以直接命中缓存，耗时会大幅降低。
• 方案2（依赖单独编译、产物存储在对应仓库artifacts/releases）：是当前的主流标准方案，初始配置工作量大，但长期收益最高，多仓库操作的成本可以通过自动化流程完全抹平。
• 方案3（二进制提交主仓库）：仅适合10人以下小团队短期过渡使用，二进制会大幅膨胀Git仓库体积、不同编译参数/系统架构的产物无法共存、版本追踪困难，属于极不规范的操作，完全不推荐长期使用。

标准优化落地流程 #

你已经在使用Docker执行构建任务，可以直接基于现有流程改造：

1. 每个依赖单独维护编译配置，固定依赖版本、编译参数、适配的系统环境，依赖版本更新时自动触发CI任务编译，产出对应架构的头文件+静态库包，打版本号存储到公司内部制品库，没有专门制品库也可以直接存在对应仓库的Release附件中。
2. 主仓库用简单的自动化脚本或者Conan/vcpkg这类C++包管理工具，统一拉取对应版本的依赖制品，不需要拉取源码，依赖安装耗时可以从小时级降到秒级。
3. 保留所有依赖的全量源码编译Dockerfile，制品丢失或者需要调整编译参数时，可以一键重编译所有依赖，不需要人工介入。

内容的提问来源于stack exchange，提问作者Chris