文档首页> Linux命令> 蓝易云cdn:在C/C++中使用vcpkg

蓝易云cdn:在C/C++中使用vcpkg

发布时间：2026-02-02 00:01       

在 C/C++ 工程里用 vcpkg，本质是在做一件“工程治理”的事：把第三方依赖从“各自电脑手工装、装到哪算哪”，升级成“团队可复现、CI/CD 可落地、版本可控”的供应链流程 🚀。你少踩坑，构建更稳定，交付周期也更可控——这就是价值。

1) 先把 vcpkg 装起来（一次性动作）

git clone https://github.com/microsoft/vcpkg.git
cd vcpkg
# Windows:
bootstrap-vcpkg.bat
# Linux/macOS:
./bootstrap-vcpkg.sh
​

逐行解释：

  • git clone ...：把 vcpkg 仓库拉到本地（你后续的工具链、包缓存、triplet 都围绕这份目录工作）。
  • cd vcpkg：进入 vcpkg 根目录，后续命令都在这里执行最稳。
  • bootstrap-vcpkg.*：编译/初始化 vcpkg 可执行程序（相当于“把包管理器本体装好”）。

2) 两种用法：经典模式 vs 清单模式（团队建议直接上清单模式）

  • 经典模式：你手动 vcpkg install xxx，安装结果对这份 vcpkg 实例下的项目“共享可见”。适合个人试验、临时验证。
  • 清单模式（Manifest）：在项目里放 vcpkg.json，把依赖“写进项目配置”，构建时自动解析并安装，协作最稳定 ✅。官方也明确更推荐多数用户采用清单模式。(Microsoft Learn)

3) CMake 集成（最常见、最稳的工程化路径）🧩

3.1 关键点：用 vcpkg 的 CMake toolchain

CMake 在第一次配置时会在 project() 阶段决定工具链；因此 所有影响 vcpkg 的变量（比如 triplet）要在第一次 project() 之前就确定，否则你会遇到“改了不生效/需要清 cache”的经典坑。(Microsoft Learn)

cmake -S . -B build \
  -DCMAKE_TOOLCHAIN_FILE="D:/vcpkg/scripts/buildsystems/vcpkg.cmake"
cmake --build build
​

逐行解释：

  • -S . -B build：源码在当前目录，构建输出到 build/，避免污染源码目录（工程规范）。
  • -DCMAKE_TOOLCHAIN_FILE=...vcpkg.cmake：告诉 CMake 用 vcpkg 的工具链脚本；它会把 vcpkg 的包路径注入到 find_package/find_library/find_path 等查找逻辑里。(Microsoft Learn)
  • cmake --build build：按生成器规则编译（VS/Ninja/Make 都能吃）。

3.2 清单模式落地：在项目根目录放 vcpkg.json

{
  "name": "demo-app",
  "version-string": "0.1.0",
  "dependencies": [
    "fmt"
  ]
}
​

逐行解释：

  • name/version-string：项目元数据（让依赖治理更“可审计”）。
  • dependencies：声明依赖包名（这里示例 fmt）。
  • 当你用 vcpkg toolchain 配 CMake 时，工具链会检测到 vcpkg.json 并自动触发依赖安装（你不用手动一个个装）。(Microsoft Learn)

3.3 CMakeLists.txt 里怎么“用库”

cmake_minimum_required(VERSION 3.20)
project(demo LANGUAGES CXX)

find_package(fmt CONFIG REQUIRED)

add_executable(demo main.cpp)
target_link_libraries(demo PRIVATE fmt::fmt)
​

逐行解释：

  • project(...)：CMake 正式进入工程配置阶段（所以 toolchain 要在这之前就设好）。
  • find_package(fmt CONFIG REQUIRED)：让 CMake 通过 vcpkg 注入的查找路径去找到 fmt 的配置包。
  • target_link_libraries(... fmt::fmt)：链接到 fmt 导出的目标（现代 CMake 推荐方式，比手写 include/lib 路径更稳）。

4) Visual Studio / MSBuild 集成（Windows 常用）🛠️

vcpkg integrate install
​

逐行解释：

  • 这是“用户级集成”：让 MSBuild/VS 在后台自动识别你当前用户的 vcpkg 实例，同时会提示 CMake 集成该用的 toolchain 路径。(Microsoft Learn)
  • 注意：它不是“给你多出一个菜单”，更像是“把依赖解析这条管道打通”，属于隐式集成（工程体验更顺滑）。

5) Triplet：你要把“目标环境”说清楚（别让构建像盲盒）

Triplet 用一个名字描述 CPU/OS/编译器/运行库 组合，比如 x64-windows、x64-linux。这决定了你装的是哪一套二进制/编译参数。(Microsoft Learn)
常见做法是在 CMake 配置时指定：

cmake -S . -B build ^
  -DCMAKE_TOOLCHAIN_FILE="D:/vcpkg/scripts/buildsystems/vcpkg.cmake" ^
  -DVCPKG_TARGET_TRIPLET=x64-windows
​

逐行解释：

  • VCPKG_TARGET_TRIPLET=...：明确告诉 vcpkg“装哪一种目标包”（否则可能按默认推断，团队协作时容易不一致）。
  • 如果你切换了 triplet，建议清理 build/ 重新配置，避免缓存污染（这是 CMake 的缓存机制，不是你手滑）。

6) 提效加分项：二进制缓存（团队/CI 直接起飞）📦

vcpkg 支持通过环境变量 VCPKG_BINARY_SOURCES 配置二进制缓存来源（本地目录、NuGet 等），以减少重复编译与下载。(Microsoft Learn)

# 示例：把缓存落到本地目录（Windows PowerShell 写法类似，注意路径即可）
set VCPKG_BINARY_SOURCES=files,D:\vcpkg-cache,readwrite
​

逐行解释：

  • files,...：表示用“文件系统目录”做缓存后端。
  • readwrite：允许写入缓存（CI 里通常一台负责写，其它只读也行）。
  • 结果：同一依赖在不同项目/不同机器上能“复用构建产物”，成本立刻下降，交付效率立刻上来。

原理解释表（可直接用于 WordPress 经典编辑器）

如果你按上面这条路径走（清单模式 + CMake toolchain + 明确 triplet + 缓存），vcpkg 就不再是“装库工具”，而是你 C/C++ 工程的依赖交付管道：可控、可复现、可规模化。你负责写业务，它负责把依赖这摊“琐碎但致命”的事变成标准化流程 😄