在 CentOS 上做 C++ 开发，依赖管理往往不是“能不能装上”的问题，而是后续是否好维护：版本能不能控住、团队环境能不能统一、构建脚本能不能长期复用。下面按从轻到重的几种常见方案展开，先讲系统自带工具能解决什么，再看 CMake、vcpkg、Conan 和 Docker 分别适合什么场景，方便你根据项目规模和协作方式做选择。
先按项目规模选方案
如果项目只是依赖少量系统库，直接使用 yum/dnf 往往最快；如果已经进入规范化构建阶段，CMakeLists.txt 应该成为依赖管理的组织中心；当第三方库数量增多、版本要求更细，通常就要引入 vcpkg 或 Conan；而一旦涉及多人协作、持续集成或跨环境交付，Docker 带来的环境隔离会更有价值。
可以把它理解为一条逐步升级的路径：系统包解决“装上能用”，CMake解决“工程能构建”，vcpkg/Conan解决“第三方库可控”，Docker解决“环境一致”。
用 yum/dnf 处理基础依赖
CentOS 默认的包管理器适合安装系统级 C++ 依赖，包括编译工具链、头文件以及静态库或动态库。这种方式直接、稳定，尤其适合依赖项本来就在系统仓库里的项目。
常用安装命令
sudo yum update -y
sudo yum groupinstall -y "Development Tools"
sudo yum install -y boost-devel openssl-devel这里分别对应三件事：
- 更新系统包：
sudo yum update -y - 安装开发工具集，包含
gcc、g++、make等：sudo yum groupinstall -y "Development Tools" - 安装具体开发库，例如 Boost 和 OpenSSL：
sudo yum install -y boost-devel openssl-devel
适用边界
它的优点是简单、稳定、和系统环境结合紧密；问题也很明显：当你需要自定义版本、锁定特定发行版本，或者同一台机器上需要多版本共存时，系统仓库的灵活度通常不够。对版本稳定性要求高、并且依赖能直接从系统仓库获得的项目，这仍然是优先级很高的方案。
把 CMake 作为依赖组织中心
CMake 不只是生成构建文件的工具，在现代 C++ 项目里，它更像是依赖关系的统一入口。即便库本身是通过系统包、vcpkg 或 Conan 安装的，最终通常也会回到 CMakeLists.txt 中完成查找、配置和链接。
依赖查找与链接怎么写
常见做法包括：
- 用
find_package查找依赖库，例如：find_package(Boost REQUIRED COMPONENTS system filesystem) - 用
target_link_libraries把依赖挂到目标上，例如：target_link_libraries(MyProject Boost::system Boost::filesystem)
基本构建流程
在项目目录中创建 build 目录后，可以直接执行：
cmake ..
make原文里的 cmake .. && make 本质上也是这一流程。
对于结构化项目，CMake 的价值不只是“能编译”，而是能把依赖查找、编译选项和目标链接收拢到同一套工程描述里，后续替换依赖来源时，改动面也会更可控。
第三方库较多时，用 vcpkg 减少手工编译
当项目开始依赖多个第三方库，手动下载和编译会迅速变成负担。vcpkg 的优势就在于把“下载、编译、安装、对接 CMake”这几步串起来，适合希望尽快把第三方依赖接入项目的场景。
安装与使用步骤
git clone https://github.com/microsoft/vcpkg.git && cd vcpkg && ./bootstrap-vcpkg.sh安装依赖时使用：
./vcpkg install <library-name>:<triplet>例如：
./vcpkg install openssl:x64-linux如何接入 CMake
有两种常见方式：
- 在
CMakeLists.txt中添加：set(CMAKE_TOOLCHAIN_FILE /path/to/vcpkg/scripts/buildsystems/vcpkg.cmake) - 或者在命令行中指定：
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/vcpkg/scripts/buildsystems/vcpkg.cmake ..
vcpkg 最适合的场景，是你已经进入规范化工程阶段，但还不想在每个第三方库上反复处理源码编译、路径配置和平台差异。对中小型项目来说，它通常比纯手工维护轻松得多。
需要版本控制和团队复用时，考虑 Conan
Conan 是更偏工程化、团队化的 C++ 包管理方案。它支持二进制包分发、版本管理以及中央仓库和私有仓库，这也是它在企业项目中更常见的原因。
基本流程
先安装 Conan：
pip install conan然后在项目根目录创建 conanfile.txt 或 conanfile.py。简单依赖可以写成下面这样：
[requires]
boost/1.75.0
[generators]
cmake安装依赖时执行：
conan install .. --build=missing与 CMake 的集成方式
在 CMakeLists.txt 中加入：
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()之后再通过 target_link_libraries 链接依赖。
如果团队里既有公共第三方库，也有内部复用组件，Conan 的仓库化管理会比单纯依赖系统包或本地目录更清晰。它的门槛比 vcpkg 略高，但换来的是更强的版本控制和共享能力。
用 Docker 统一开发与构建环境
依赖装对了，不代表环境问题就结束了。不同机器上的编译器、库版本、构建工具差异，仍然可能导致“在我机器上能运行”的问题。Docker 的作用就是把这些环境差异一起打包隔离掉。
示例 Dockerfile
FROM centos:latest
RUN yum update -y && yum install -y gcc-c++ cmake openssl-devel
COPY . /app
WORKDIR /app
RUN mkdir build && cd build && cmake .. && make
CMD ["./build/MyProject"]构建与运行命令
docker build -t myproject .
docker run -it myproject这种方式特别适合团队协作、CI/CD 或跨平台部署。它的代价是要额外理解 Dockerfile、镜像构建和容器运行方式，但换来的是环境一致性，长期看通常值得。
为什么不建议手动管理依赖
手动管理通常指自行下载源码、编译后安装到 /usr/local，或者把第三方库存进项目的 libs 目录，再在 CMakeLists.txt 里直接写路径，例如：
target_link_libraries(MyProject /path/to/libs/libboost_system.a)它的确最灵活，但问题也最集中：版本升级麻烦、依赖冲突频繁、迁移成本高，而且项目一旦交给别人维护，隐性成本会很快放大。除非项目极其简单，或确实有特殊限制，否则不建议把这种方式作为长期方案。
实操中怎么选更稳妥
如果只是小项目或基础环境搭建，优先从 yum/dnf 和 CMake 开始；如果第三方依赖逐渐增多，优先考虑 vcpkg；如果团队需要明确的版本治理、私有仓库和内部组件复用，Conan 更合适；如果项目还要保证多人机器、测试环境和部署环境一致，最好进一步配合 Docker。
一个比较常见、也比较稳妥的组合是：系统层用 yum 安装编译工具，项目层用 CMake 组织构建，第三方库用 vcpkg 或 Conan 管理，最终在 Docker 里固化环境。这样从本地开发到团队协作，链路会清晰很多。
