在 CentOS 环境里做 C++ 项目，真正耗时间的往往不是写代码，而是把编译链、库版本和运行环境理顺。系统自带包适合快速起步，CMake 负责把依赖写进构建流程，vcpkg 和 Conan 适合统一第三方库版本，而手动编译和 Docker 则分别对应“必须指定版本”和“环境必须一致”这两类问题。
下面按实际开发中的决策顺序来拆解：先装基础工具链，再决定项目依赖由谁管理，最后再看是否需要源码安装或容器化隔离。看完后，你可以根据项目规模、团队协作方式和版本控制要求，选出更省事的一套组合。
先用系统包管理器装好基础依赖
如果你是在一台干净的 CentOS 机器上开始开发，第一步通常不是研究包管理器生态，而是先把系统级开发环境补齐。CentOS 7 及以下主要用 yum，CentOS 8 及以上则使用 dnf。
这一层最适合安装编译器、构建工具，以及系统仓库里已经比较成熟的开发库。优点是直接、稳定、能自动解决依赖关系，适合本地开发环境初始化和服务器基础环境准备。
# 更新系统
sudo yum update -y # CentOS 7
sudo dnf update -y # CentOS 8+
# 安装开发工具链（gcc/g++、make、cmake等）
sudo yum groupinstall -y "Development Tools" # CentOS 7
sudo dnf groupinstall -y "Development Tools" # CentOS 8+
# 安装常用C++依赖库（以openssl为例）
sudo yum install -y openssl-devel # 或 sudo dnf install -y openssl-devel常见库的安装方式也基本一致：
- 数学库：
sudo yum install -y libm-devel - 线程库：
sudo yum install -y pthread-devel - zlib 压缩库：
sudo yum install -y zlib-devel - libxml2 解析库：
sudo yum install -y libxml2-devel
如果项目只依赖这些系统仓库里现成的库，这一步往往就够了；但一旦涉及跨平台、多版本控制或团队统一依赖，就需要把管理逻辑继续上移。
把依赖声明写进 CMake 构建流程
装完系统库之后，下一步是让项目自己知道“需要哪些库、该怎么链接”。这正是 CMake 的价值所在。它不是包管理器，但它能把依赖查找、链接和构建过程写成可重复执行的规则。
对中小型项目来说，系统包管理器负责安装，CMake 负责声明和链接，这是一套很常见的组合。
# CMakeLists.txt示例
cmake_minimum_required(VERSION 3.10)
project(MyProject)
# 添加可执行文件
add_executable(MyProject main.cpp)
# 查找并链接系统依赖库（以OpenSSL为例）
find_package(OpenSSL REQUIRED)
target_link_libraries(MyProject PRIVATE OpenSSL::SSL OpenSSL::Crypto)构建步骤如下：
mkdir build && cd build # 创建构建目录
cmake .. # 生成Makefile
make # 编译项目这种方式的关键好处在于，依赖配置不再散落在开发者本地命令历史里，而是固化在 CMakeLists.txt 中。项目越复杂，这种声明式写法越能减少手动改路径、补链接参数的成本。
需要跨平台统一第三方库时，用 vcpkg
当项目开始依赖 Boost、fmt 这类第三方 C++ 库时，只靠系统仓库往往不够灵活。这时可以考虑 vcpkg。它更适合希望在不同开发机上保持一致依赖集合的团队，尤其是同时面向 Linux、Windows 等平台的项目。
# 克隆vcpkg仓库并编译
git clone https://github.com/microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
# 安装依赖库（以Boost为例）
./vcpkg install boost
# 集成到CMake（在CMakeLists.txt中添加）
set(CMAKE_TOOLCHAIN_FILE /path/to/vcpkg/scripts/buildsystems/vcpkg.cmake)vcpkg 的核心价值不只是“能装库”，而是把第三方库获取方式纳入统一流程。这样项目成员不需要分别去系统里找库路径，也更容易在不同机器上复现同样的依赖状态。
需要版本锁定和仓库能力时，用 Conan
如果你的项目已经进入多人协作、持续集成甚至企业内部分发阶段，Conan 通常会更常见。它通过 conanfile.txt 声明依赖，支持远程仓库和版本控制，适合对依赖可追溯性要求更高的场景。
# 安装Conan（Python包）
pip install conan
# 创建conanfile.txt（声明依赖）
# 示例：依赖zlib 1.2.11
[requires]
zlib/1.2.11
[generators]
cmake
# 安装依赖
mkdir build && cd build
conan install ..
# 生成CMake配置文件
# 构建项目（结合CMake）
cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
make这里最值得关注的是版本锁定能力。比如示例里直接写了 zlib/1.2.11，这意味着项目依赖的不是一个模糊的“zlib”，而是一个明确版本。对于要长期维护的项目，这能明显降低升级和回归排查的成本。
仓库里没有目标版本时，再考虑手动源码安装
并不是所有库都能在系统仓库、vcpkg 或 Conan 里直接拿到。遇到冷门库、补丁版库，或者必须指定某个上游源码版本时，手动编译安装仍然是必要手段。但这类方式更适合作为补充方案，而不是默认方案。
# 下载源码（以libcurl为例）
wget https://curl.se/download/curl-7.88.1.tar.gz
tar -xzvf curl-7.88.1.tar.gz
cd curl-7.88.1
# 编译并安装
./configure --prefix=/usr/local
make
sudo make install安装完成后，最好立即检查二进制实际链接到了哪些动态库：
ldd ./your_program
# 查看动态库依赖这一类问题最常见的坑，是库装到了 /usr/local/lib，但运行时动态链接器没有及时识别。必要时需要更新 ldconfig 缓存，否则程序编译通过了，启动时仍然会报找不到库。
多人协作或部署环境复杂时，用 Docker 固定依赖环境
当问题已经不再只是“这台机器怎么装库”，而变成“开发、测试、生产怎么保证一致”时，Docker 的优先级就会上升。它不是替代 CMake、vcpkg 或 Conan，而是把这些步骤放进一个可重复构建的隔离环境里。
FROM centos:latest
# 安装依赖
RUN yum update -y && yum install -y gcc-c++ cmake openssl-devel make
# 复制项目文件
COPY . /app
WORKDIR /app
# 构建项目
RUN mkdir build && cd build && cmake .. && make
# 设置启动命令
CMD ["./build/MyProject"]构建和运行命令如下：
docker build -t myproject . # 构建镜像
docker run -it myproject # 运行容器对于需要多人协作、CI 构建或跨服务器部署的项目，这种做法能明显减少“本地能跑、线上不行”的环境偏差。尤其当项目依赖项较多时，把工具链和库版本都写进镜像，维护成本会比手工配机低得多。
怎么选：按项目复杂度组合使用
这几种方式并不是互斥关系，实际开发里更常见的是组合使用：
- 本地快速开发：系统包管理器 + CMake
- 跨平台第三方库较多：CMake + vcpkg
- 企业项目、版本要求严格：CMake + Conan
- 必须指定特殊源码版本：在以上方案之外补充手动编译
- 多人协作与部署一致性要求高：把依赖安装过程收进 Docker
如果要用一句话概括，CentOS 下的 C++ 依赖管理没有单一标准答案，关键在于先分清你解决的是“装库问题”“构建问题”“版本问题”，还是“环境一致性问题”。问题类型判断对了，工具选择通常就不会偏。
