1. 课程导入与依赖管理全景
在开始学习具体的工具之前，先建立一个整体认知：跨平台 C/C++ 依赖管理到底难在哪里，为什么它不像 Python 的 pip、Node.js 的 npm 那样“一条命令解决”，以及我们这门课会沿着怎样的路线逐步掌握它。这一节不涉及具体命令，但会决定你后面每一节的学习视角。
一、C/C++ 依赖管理的核心挑战
C/C++ 没有官方统一的包管理器，这是所有问题的根源。语言标准只规定了语法和语义，没有规定“如何获取第三方库”。于是每个平台、每个编译器、每个构建系统都发展出自己的方式：Linux 上习惯用系统包管理器（apt、yum、pacman）安装 libssl-dev 这类开发包；Windows 上常见的是下载 zip、手动配置包含目录和库目录；macOS 上则常用 Homebrew。同一份源码，在三台机器上可能得到三种不同的依赖获取路径。
更麻烦的是 ABI（应用二进制接口）兼容性。C++ 没有稳定的 ABI 标准，不同编译器（GCC、Clang、MSVC）、不同标准库（libstdc++、libc++、MSVC STL）、不同编译选项（-D_GLIBCXX_USE_CXX11_ABI、/MT 与 /MD）都会影响二进制能否链接。一个在 Ubuntu 22.04 上用 GCC 11 编译好的静态库，拿到 Windows 上基本无法直接使用。这意味着依赖管理不仅是“下载”，还涉及“为当前工具链重新构建”。
第三个挑战是传递依赖与版本冲突。假设你的项目依赖 A，A 依赖 B 1.2，而你的另一个依赖 C 需要 B 2.0。如果 B 的 1.x 和 2.x 接口不兼容，就会产生冲突。C/C++ 没有像 Maven 那样的依赖仲裁机制，需要开发者自己决定是升级、降级还是隔离。
二、典型场景与工具链生态
面对这些挑战，实际工程中形成了多种应对策略，可以按“依赖来源”和“构建方式”两个维度来理解。
第一类是系统包管理器。在 Linux 上，apt install libcurl4-openssl-dev 会同时安装头文件、静态库和动态库，并注册到系统路径。优点是简单、与系统集成好；缺点是版本受发行版限制，跨平台不可移植，且难以锁定精确版本。
第二类是源码内嵌与子模块。把第三方库源码直接放进项目，或用 Git submodule 引入。优点是版本完全可控、可跨平台编译；缺点是仓库体积大、更新麻烦、需要自己维护构建脚本。
第三类是现代包管理器，以 vcpkg、Conan、Hunter 为代表。它们把“下载源码 + 用当前工具链编译 + 安装到本地缓存”自动化，并支持版本锁定和传递依赖解析。例如 vcpkg 的清单模式：项目根目录放一个 vcpkg.json，声明依赖，然后 vcpkg install 就会按当前 triplet（如 x64-windows、x64-linux）构建并安装。Conan 则用 conanfile.txt 或 conanfile.py 描述依赖，通过 profile 指定编译器、架构和构建类型。
第四类是构建系统自带的依赖获取。CMake 从 3.11 开始提供 FetchContent，可以在配置阶段下载并纳入构建；ExternalProject_Add 则更适合在构建阶段处理。这类方式与构建系统深度绑定，适合依赖数量不多、希望“一次配置、处处构建”的项目。
这些工具并非互斥。一个真实项目可能用 vcpkg 管理大部分第三方库，同时用 FetchContent 引入一个尚未进入 vcpkg 的小型头文件库，再用系统包管理器安装构建工具本身（如 CMake、Ninja）。理解它们的边界和组合方式，比记住某个命令更重要。
三、学习路线图
本课程共 30 节，整体按“先建立认知，再掌握工具，最后落地实战”的顺序推进。前几节会先讲清楚依赖的获取、构建、链接三个阶段分别发生了什么，以及头文件搜索路径、库搜索路径、链接顺序这些基础概念。随后进入具体工具：系统包管理器的使用与局限、Git submodule 的维护方式、vcpkg 的清单模式与经典模式、Conan 的 profile 与远程仓库、CMake 的 find_package 与 FetchContent。中段会重点处理跨平台问题：如何用工具链文件切换编译器、如何为不同 triplet 构建依赖、如何处理 Windows 上的 DLL 导出与运行时路径。后段则进入综合实战：从零搭建一个跨 Linux/Windows/macOS 的项目，管理 5～8 个第三方依赖，并处理版本冲突、ABI 不匹配、链接错误等典型故障。
需要强调的是，工具会变，但底层机制相对稳定。无论用 vcpkg 还是 Conan，最终都要落到“头文件在哪里、库文件在哪里、链接器按什么顺序找符号”这三个问题上。把这三件事想清楚，遇到新工具时就能快速判断它帮你解决了哪一层问题。
四、一个最小示例：同一依赖的三种获取方式
为了直观感受差异，以常用的 JSON 库 nlohmann/json 为例。方式一，在 Ubuntu 上执行 sudo apt install nlohmann-json3-dev，头文件被安装到 /usr/include/nlohmann/，CMake 中直接 find_package(nlohmann_json REQUIRED) 即可。方式二，用 Git submodule 把仓库放到 third_party/json，在 CMake 中 add_subdirectory(third_party/json)，然后链接 nlohmann_json::nlohmann_json。方式三，在 vcpkg.json 中写 {"dependencies": ["nlohmann-json"]}，执行 vcpkg install 后，通过工具链文件让 CMake 自动找到它。
三种方式得到的头文件内容相同，但版本控制能力、跨平台一致性、团队协作成本完全不同。这正是后续每一节要展开比较的内容。现在只需要记住：依赖管理不是单一命令，而是一组关于“来源、构建、集成”的决策。