C++ 包管理工具概览
C++ 历史上缺乏像 Cargo、npm 那样的事实标准包管理器，实践中常见 专用包管理器 、CMake 内嵌方案 、系统包管理 与 构建系统一体方案 并存；文中对 vcpkg、Conan 与 CMake 生态 着墨较多，亦覆盖 xmake、Meson、Bazel 等，便于对照选型。名称上 Conan （JFrog 生态）常被口误写成 "canon"。下文按类别归纳主流工具、特点与选型思路，并附生态关系图 、与 CMake 集成方式 及选型决策示意 ；版本与命令以各项目官方文档为准。
目录
- 生态中的位置（示意）
- 工具总览表
- [vcpkg、Conan 与 CMake 的常见协作](#vcpkg、Conan 与 CMake 的常见协作)
- 最小配置片段（示例）
- vcpkg（微软）
- Conan
- CPM.cmake
- Hunter
- [FetchContent（CMake 内置）](#FetchContent（CMake 内置）)
- 系统包管理器
- Bazel
- build2
- Spack
- xmake
- Meson
- 选型决策树（示意）
- 其他与选型建议
- 延伸阅读
- 免责声明
生态中的位置（示意）
CMake 侧拉依赖
依赖来源（多选一或组合）
你的工程
提供编译器与系统 -dev
源码
CMakeLists.txt
vcpkg ports
Conan 包 / ConanCenter
apt / brew / dnf
FetchContent / CPM
Hunter
读图要点 ：vcpkg / Conan 多在配置 CMake 之前或之中 把库装到约定前缀或通过 toolchain/generator 注入；CPM/FetchContent 则在 CMake 配置阶段拉源码进构建树。
工具总览表
| 工具 |
类型 |
核心特点 |
典型场景 |
| vcpkg |
专用 C++ 包管理 |
微软开源，多为主源码构建 ，与 CMake / MSBuild 集成深，支持 manifest（vcpkg.json）、二进制缓存 |
Windows/Linux/macOS，希望统一拉依赖的 C++ 项目 |
| Conan |
专用 C++ 包管理 |
去中心化 ，二进制包 与强依赖解析，Conan 2 改进图模型与锁文件，可搭私有仓 |
多平台、多编译器、多配置，企业级与 CI 友好 |
| CPM.cmake |
CMake 脚本 |
基于 FetchContent ，单文件引入，CPMAddPackage 声明依赖 |
中小型 CMake 项目，尽量少装额外 CLI |
| Hunter |
CMake 脚本 |
ExternalProject_Add 驱动，预配置包多，工具链哈希锁版本 |
已有较重 CMake 工程，希望依赖下载构建自动化 |
| FetchContent |
CMake 内置 |
3.11+ 拉取源码加入工程，无高级版本/冲突解析 |
少量依赖（如测试框架） |
| apt/yum/brew... |
系统级 |
装编译器、CMake、系统 -dev 包；库版本常偏旧 |
基线环境，或与 vcpkg/Conan 互补 |
| Bazel |
构建 + 依赖 |
大规模 monorepo、增量与远程缓存、多语言 |
类 Google 风格超大仓 |
| build2 |
构建 + 包管理 |
类 Cargo 的一体化体验，生态相对小 |
愿意采用整套工具链的团队 |
| Spack |
领域包管理 |
HPC/科学计算，多版本、多编译器共存 |
超算、科研软件栈 |
| xmake |
构建 + 包管理 |
Lua DSL 的 xmake.lua，内置 xmake-repo，一条工具链覆盖依赖与编译 |
希望少写 CMake、跨平台原型与中小项目 |
| Meson |
构建系统 |
meson.build + Ninja 后端，wrap / subproject 拉依赖 |
追求可读配置与较快配置阶段，与 CMake 项目并存时需分工 |
vcpkg、Conan 与 CMake 的常见协作
| 方式 |
vcpkg |
Conan |
| 典型集成 |
CMAKE_TOOLCHAIN_FILE 指向 scripts/buildsystems/vcpkg.cmake ；或使用 manifest 模式在工程根放 vcpkg.json |
conan install 生成 conan_toolchain.cmake / CMakeDeps 等，再在 cmake 时 -DCMAKE_TOOLCHAIN_FILE=... 或 CMake Presets |
| 版本锁定 |
vcpkg.json 中 builtin-baseline 或 overrides（随 vcpkg 版本演进） |
Conan 2 推荐 lockfile + profile |
| 二进制复用 |
binary caching（NuGet、文件共享等，见官方文档） |
同一 profile 下命中缓存则少编译 |
| 心智模型 |
「port + triplet」决定如何编库 |
「recipe + profile + package_id」决定 ABI 与包身份 |
最小配置片段（示例）
vcpkg manifest（节选）：
json
复制代码
{
"name": "my-app",
"version": "1.0.0",
"dependencies": ["fmt", "zlib"]
}
Conan 2 conanfile.txt（节选，仅示意）：
ini
复制代码
[requires]
zlib/1.3.1
[generators]
CMakeDeps
CMakeToolchain
实际 generator 名称与布局 以 Conan 2 文档为准；配置后仍需在 CMakeLists.txt 中 find_package 并与 目标链接（与手写路径相比更易维护）。
vcpkg（微软）
| 项目 |
说明 |
| 定位 |
开源 C++ 库管理器，以从 port recipe 构建为主，支持 Windows / Linux / macOS |
| 集成 |
CMake toolchain 文件 、Visual Studio、vcpkg.json 清单模式，便于团队与 CI 复现 |
| 生态 |
官方维护大量 port（量级随时间增长），常见库如 Boost、OpenCV 等 |
| 缓存 |
支持二进制缓存（本地/远程），减轻重复编译 |
| 优点 |
上手路径清晰，与 MSVC/VS 体验好，清单模式易纳入版本控制 |
| 注意 |
首次全量构建耗时；个别 port 版本相对上游发布可能有滞后 |
Conan
| 项目 |
说明 |
| 定位 |
C/C++ 包管理器（Python 生态安装 CLI），强调按 profile （OS、编译器、ABI、构建类型）管理二进制制品 |
| 仓库 |
ConanCenter 与自建私有库（如与 Artifactory 集成） |
| Conan 2.x |
依赖图、锁文件、元数据模型重构，长期推荐新项采用 2.x |
| 优点 |
多配置/多平台下复用二进制，大企业内网分发友好，依赖解析能力强 |
| 注意 |
概念多于 vcpkg（profile、recipe、generators），学习曲线更陡 |
CPM.cmake
| 项目 |
建议 CMake |
| 机制 |
在 CMakeLists.txt 中 include(CPM) 后使用 CPMAddPackage ，底层多为 FetchContent |
| 依赖 |
通常 CMake 3.14+ ，通过 Git 等拉源码构建 |
| 缓存 |
常见缓存目录如 ~/.cache/CMake/CPM，多项目可复用 |
| 优点 |
零独立包管理器进程，配置短，适合原型与小团队 |
| 注意 |
偏源码构建；超大量依赖时无 Conan 级二进制治理 |
Hunter
| 项目 |
说明 |
| 机制 |
CMake ExternalProject_Add 等在配置/生成阶段拉取并构建依赖 |
| 特点 |
预置大量库的「Hunter 化」配方，工具链哈希锁定构建环境 |
| 优点 |
侵入 CMake 项目的方式成熟，版本可钉死 |
| 注意 |
初次或清理后 configure 时间可能很长；入门配置比重于 CPM |
FetchContent（CMake 内置）
| 项目 |
说明 |
| 能力 |
FetchContent_Declare / Populate 从 Git、URL 等拉取源码并 add_subdirectory |
| 优点 |
无第三方包管理器，最轻 |
| 注意 |
无通用「依赖图求解」，版本与传递依赖需手写或由 CPM/Hunter 代劳 |
系统包管理器
| 项目 |
说明 |
| 代表 |
Debian/Ubuntu apt ，RHEL/Fedora dnf/yum ，Arch pacman ，macOS Homebrew 等 |
| 用途 |
安装 g++、cmake、ninja 及 libfoo-dev 等系统库 |
| 优点 |
与 OS 集成、签名与策略成熟 |
| 注意 |
库版本偏发行版节奏 ，跨机器复现常与容器或 vcpkg/Conan 混用 |
Bazel
| 项目 |
说明 |
| 定位 |
Google 开源构建与依赖系统，Starlark 规则，强 hermetic 与远程缓存 |
| 优点 |
超大仓增量构建、多语言（C++/Java/Go 等）统一 |
| 注意 |
对中小型纯 C++ 项目往往过重，与 CMake 生态直连用第三方转换或桥接 |
build2
| 项目 |
说明 |
| 定位 |
build2 工具链 + 内置包管理，理念接近 Cargo 式一体体验 |
| 优点 |
概念一致、依赖与构建统一 |
| 注意 |
社区与第三方库覆盖小于 vcpkg/Conan |
Spack
| 项目 |
说明 |
| 定位 |
面向 HPC 与科学计算，同一库多版本 、多编译器、spec 组合 |
| 优点 |
复杂软件栈与超算环境友好 |
| 注意 |
通用业务 C++ 服务端日常开发较少作为首选 |
xmake
| 项目 |
说明 |
| 定位 |
构建系统 + 包管理 一体：xmake.lua 描述目标与选项，add_requires 等声明依赖，仓库 xmake-repo 维护大量包配方 |
| 与 CMake 关系 |
并行生态 ：同一组织可「新模块用 xmake、老模块 CMake」并存，但跨工程复用需约定产物（静态/动态库、头路径）或统一一种主构建 |
| 优点 |
配置短、中文文档与社区活跃；交叉编译、工具链探测对新手较友好 |
| 注意 |
企业内若已深度绑定 CMake + Conan/vcpkg ，引入 xmake 需评估 CI、IDE、代码审查 习惯；版本与包 API 以 xmake 官方文档为准 |
Meson
| 项目 |
说明 |
| 定位 |
声明式构建 ：meson.build 生成 Ninja （等）后端；依赖常通过 wrap （WrapDB / 本地 wrap 文件）或 subproject() 引入子工程 |
| 与 CMake 关系 |
常见于 GNOME/系统组件 与部分 C 库；与纯 CMake 工程无官方「互转」 ，协作方式多为 各编各的 再链接，或用 cmake subproject 等桥接（视场景） |
| 优点 |
语法可读性强；配置阶段通常比「巨型 CMake」轻快；与 pkg-config 集成成熟 |
| 注意 |
第三方 C++ 库示例仍以 CMake 为主 时，需在 Meson 侧手写 dependency() / 自定义 *.pc 等；细节见 Meson 手册 |
选型决策树（示意）
是
否
是
否
是
否
新 C++ 项目选依赖方案
必须企业内网二进制分发?
是否坚持零额外 CLI、仅 CMake?
是否以 MSVC/Windows 为主?
优先考虑 Conan + 私有仓
CPM.cmake / FetchContent
vcpkg
vcpkg 或 Conan 均可，看团队习惯
其他与选型建议
其它名称 ：cget （CMake 检索/安装）；xmake / Meson 见上文专节；conan 拼写勿与 "canon" 混淆。
简明选型：
| 诉求 |
倾向 |
| Windows 为主、快速统一依赖 |
vcpkg |
| 多平台二进制复现、企业私有制品 |
Conan |
| 仅 CMake、最少工具 |
CPM.cmake 或 FetchContent |
| 重型遗留 CMake、自动化 ExternalProject |
评估 Hunter |
| 基线编译器与系统库 |
apt/dnf/brew |
| 超大 monorepo、多语言 |
Bazel |
| HPC/多版本科学栈 |
Spack |
| 偏好 Lua 式单仓、内置包仓库 |
xmake |
| 强声明式 + Ninja、与 GLib 等栈一致 |
Meson |
延伸阅读
同仓库 CMake 与现代 C++ 构建相关文档可对照阅读，例如 hnjzsdx_doc/C++/CMake_target_include_directories_compile_definitions_link_libraries详解.md （find_package 与 target_link_libraries 的配合思路）。
免责声明
工具特性与命令随版本变化；生产选型请阅读所用工具（如 vcpkg、Conan、CMake、xmake、Meson 等）的官方文档及许可证要求。
主题：C++ 包管理、vcpkg、Conan、CPM、CMake、xmake、Meson、Bazel、Spack。