CMake与vcpkg：深挖OpenSSLConfig.cmake的查找与链接机制

1. 为什么OpenSSLConfig.cmake值得单独拆开研究

如果你用 vcpkg 装过 OpenSSL，大概率经历过这样一幕：工程里写了 find_package(OpenSSL REQUIRED)，配置时却报“Could not find a package configuration file provided by OpenSSL”。网上搜一圈，有人让你装库，有人让你改变量，还有人让你把整个 CMake 删了重来。其实很多问题都不是 OpenSSL 没装上，而是没有搞清楚 CMake 到底在找什么文件、找到之后又拿这些文件做了什么。

我最初翻 C:/vcpkg/installed/x64-windows/share/openssl/ 这个目录，只是想确认 vcpkg 有没有把库文件放对位置。结果发现里面躺着一个 OpenSSLConfig.cmake，顺手打开之后才意识到，这就是整个 CMake 查找机制的“钥匙”。我原本以为这种自动生成的文件只需要编译过就行，不用管里面写了什么，但实际排查几轮之后，越来越觉得它值得完整拆开研究，尤其是“为什么这样写”“哪些变量会被外部命中”“导入目标是怎么被注册出来的”，这些才是真正能帮你解决构建问题的地方。

这篇文章适合的是已经会用 vcpkg 装包、但对 CMake 的 package 查找机制只停留在“能跑就行”阶段的 C/C++ 开发者。看完你至少能回答三件事：vcpkg 生成的 OpenSSLConfig.cmake 和 CMake 自带的 FindOpenSSL.cmake 是什么关系；自己工程里的 OpenSSL::SSL、OpenSSL::Crypto 到底从哪来；跑出链接错误时应该去翻哪个文件、看哪一行。

1.1 find_package 的两种模式，vcpkg 替你选了哪条路

要理解 OpenSSLConfig.cmake 的重要性，先得说清楚 find_package 的机制。CMake 里查找第三方库有两种模式：Module Mode 和 Config Mode。Module Mode 是 CMake 自带的模块文件干活，比如去找 OpenSSL 时会优先查找名为 FindOpenSSL.cmake 的脚本，由这个脚本去调用 find_path、find_library 猜测头文件和库的位置。Config Mode 则是直接打开包本身提供的 OpenSSLConfig.cmake，由这个文件把真实安装路径、编译选项、链接目标一次性交代清楚。

问题来了：这两种模式不是开发者手动选的，而是 CMake 根据目标文件能不能找到自动决定的。CMake 官方文档规定的搜索顺序虽然有些细节差异，但绝大多数场景下的实际行为是：如果包自带 xxxConfig.cmake 并且搜索路径覆盖到了它，CMake 会优先走 Config Mode，而不会去管 Module Mode 里那个 FindOpenSSL.cmake 写得多聪明。

vcpkg 的整套集成思路其实就是围绕 Config Mode 设计的。你在 CMake 命令行里带上 -DCMAKE_TOOLCHAIN_FILE=.../vcpkg/scripts/buildsystems/vcpkg.cmake 之后，vcpkg 的 toolchain 会在配置阶段自动把安装目录根路径 installed/${VCPKG_TARGET_TRIPLET} 注入到 CMake 的搜索路径里。这样一来，OpenSSLConfig.cmake 就在 CMake 的“视野范围”内了。没有这个 toolchain，你就算把库装到硬盘上，配置阶段也看不到所谓的“包配置文件”，于是报错。

这也能解释为什么很多新手直接把 vcpkg install openssl 跑完，下一步却依然找不到包。vcpkg 是一个“包管理器”，不是把库下载下来扔到系统 PATH 里就算完的，它默认要求你的工程通过 toolchain 方式加入它管理的那套搜索体系。理解了这一点，后续很多报错都不用再猜。

1.2 拆文件之前，先认清三个文件的角色

打开 installed/${VCPKG_TARGET_TRIPLET}/share/openssl/ 目录，你通常会看到几个名字相似的文件。大多数人的第一反应是随便点开一个最大的，看两行就关掉。但其实这几个文件的分工差异很明显，下面直接列出来：

• OpenSSLConfig.cmake：入口文件，回答“OpenSSL 是否可用”并处理组件检查，最终会把真正注册目标的文件引进来。
• OpenSSLConfigVersion.cmake：版本记录文件，给 find_package(OpenSSL 3.0 REQUIRED) 这种带版本要求的查询做比对。
• OpenSSLTargets.cmake：真正的核心内容，里面定义了 OpenSSL::SSL、OpenSSL::Crypto 等导入目标，以及每个目标关联的头文件目录、库文件路径、编译宏。
• 如果安装的是带 Debug/Release 两套构建的版本，还可能看到 OpenSSLTargets-debug.cmake 和 OpenSSLTargets-release.cmake，分别记录不同配置下各自的导入库路径。

其中 OpenSSLConfig.cmake 更像一个“穿针引线”的角色，它承担了兼容旧工程、处理找不到目标时报错信息、调用 targets 文件这些杂活。而 OpenSSLTargets.cmake 才是真正被工具链“喂”给链接器的最终答案。后面几节的拆解会围绕这两个文件展开，先把入口逻辑讲透，再看目标本身。

2. 从文件内部看 OpenSSLConfig.cmake 的连接逻辑

直接打开这份文件时，我不建议抱着“背下来”的心态去读。vcpkg 生成的 config 文件通常有比较固定的套路，重点在于识别套路而不是记忆某一段文本。下面我会拆成三块介绍，每块对应一个你以后排查时会反复接触的知识点。

2.1 入口逻辑：先判目标是否已存在，再决定要不要重新加载

OpenSSLConfig.cmake 的开头一般会有一段防御性判断，大致思路如下：

cmake复制if(NOT TARGET OpenSSL::Crypto)
  include("${CMAKE_CURRENT_LIST_DIR}/OpenSSLTargets.cmake")
endif()

这段代码的意思是：如果当前 CMake 工程里还没有 OpenSSL::Crypto 这个导入目标，就加载 OpenSSLTargets.cmake 来创建它；如果已经存在了，说明之前有其他 find_package 或者父工程已经把这个目标注册过，不重复加载。

我最早觉得这只是随手写的防御逻辑，但后来真的踩过一次坑。当时我的项目同时通过 add_subdirectory 引入了两个第三方子模块，各自都调用了 find_package(OpenSSL REQUIRED)。如果 config 文件没有做这个“目标是否已存在”的判断，后一次加载就会报“目标 OpenSSL::Crypto 已存在”的 duplicate target 错误。CMake 对导入目标的重复定义是非常敏感的，通常不会只给个 warning 就放过，而是直接报错。

所以以后再看到类似的 if(NOT TARGET ...) 判断，先别跳过，它是在处理多模块工程的重复查找冲突。这也是 vcpkg 的 config 文件比手写 Find 模块更稳的原因之一，因为重复加载问题已经被提前考虑过了。

2.2 兼容变量区：老工程的救命稻草

Config 文件里还经常能看到一组名为 OPENSSL_* 的普通变量定义。比如：

cmake复制set_and_check(OPENSSL_INCLUDE_DIR "${PACKAGE_PREFIX_DIR}/include")
set_and_check(OPENSSL_CRYPTO_LIBRARY "${PACKAGE_PREFIX_DIR}/lib/crypto.lib")
set_and_check(OPENSSL_SSL_LIBRARY "${PACKAGE_PREFIX_DIR}/lib/ssl.lib")

这些变量和 CMake 老模块 FindOpenSSL.cmake 中定义的变量名称是刻意保持一致的，目的就是为了让那些还在使用 include_directories(${OPENSSL_INCLUDE_DIR})、target_link_libraries(... ${OPENSSL_LIBRARIES}) 的老项目在新体系下也能工作。

不过说句实话，这种传统变量只是“兼容性出口”，并不推荐新工程继续用。因为普通变量不会自动传递依赖关系。你链接了 ssl 库，CMake 不会因此自动帮你把 crypto 也加上；但如果用导入目标 OpenSSL::SSL，它内部声明了对 OpenSSL::Crypto 的依赖，链接器处理时会把两个库都带上，这就是 target-based 结构的优势。

从 OpenSSL 自身的依赖关系也能看出这一点：libssl 依赖 libcrypto，任何只是表面上链接了 ssl 而没链接 crypto 的工程在链接阶段大概率会出事。用 variables 要么你自己记得同时加两个库，要么就得折腾 OPENSSL_LIBRARIES 的拼装。而用 target 就完全不需要关心这些。

2.3 组件检查逻辑：COMPONENTS 到底怎么生效

很多人会在 CMakeLists 里写：

cmake复制find_package(OpenSSL REQUIRED COMPONENTS SSL Crypto)

也见过只写 REQUIRED、不带 COMPONENTS 的做法。区别在哪里？在 config 模式下，组件检查是通过 OpenSSLConfig.cmake 尾部类似 check_required_components(OpenSSL) 的宏来实现的。

check_required_components 的行为说起来不复杂：它检查用户要求的每个组件在 CMake 侧是否都有对应的 OpenSSL_<Component>_FOUND 变量被置为 TRUE，如果任何一个组件缺失，就会把 OpenSSL_FOUND 强制设为 FALSE，随后触发 find_package 的 REQUIRED 报错。

vcpkg 的 OpenSSL 端口在正常安装后，SSL 和 Crypto 这两个组件都是存在的。但在某些自定义构建里，如果只装了 openssl 的某个子集，或者组件名拼错了，比如 openssl:Crypto，那么很可能出现“库里明明有文件却提示找不到组件”的情况。此时去 OpenSSLConfig.cmake 尾部看 set(OpenSSL_SSL_FOUND 1)、set(OpenSSL_Crypto_FOUND 1) 这类标记是否存在，会比瞎猜有效率得多。

需要说明的是，不同版本 vcpkg 生成的 config 文件细节并不完全相同，但“入口判断 + targets 引入 + 变量兼容 + 组件检查”这么一个大框架基本不会变。搞懂框架之后，具体某一行只是实现差异而已。

2.4 OpenSSLTargets.cmake 里埋着真正要紧的信息

真正写操作流程的时候，大多数人不会去记 OpenSSL::SSL 的库文件全路径，因为 IDE 和构建系统会自动处理。但凡链接阶段出了事，你就得回到 OpenSSLTargets.cmake 去确认你实际链接的库到底是哪个。

在 OpenSSLTargets.cmake 中，核心结构通常长这样：

cmake复制add_library(OpenSSL::Crypto SHARED IMPORTED)

set_target_properties(OpenSSL::Crypto PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
)

if(EXISTS "${_IMPORT_PREFIX}/lib/crypto.lib")
  set_target_properties(OpenSSL::Crypto PROPERTIES
    IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/crypto.lib"
    IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/crypto-3-x64.dll"
  )
endif()

注意这里有两个细节。第一个是把 add_library 的类型定成了 SHARED IMPORTED 还是 STATIC IMPORTED，这取决于你安装 vcpkg 时选择的 triplet。同一个 OpenSSL 端口，用 x64-windows 装出来就是动态库，库文件形态是 crypto.lib 导入库加 crypto-3-x64.dll 运行库；用 x64-windows-static 装出来则是静态库，不会出现 DLL。

第二个是 IMPORTED_IMPLIB 和 IMPORTED_LOCATION 的区别。前者是在 Windows 上使用 DLL 时配套的导入库（链接期用），后者是实际运行时的 DLL 路径（运行期用）。很多用 MSVC 的开发者在链接阶段没有报错、一跑程序就提示找不到 crypto-3-x64.dll，往往就是因为只把 build 目录里的 exe 拷走了，没有把 DLL 一起带过去。打开 targets 文件后能清楚看到 DLL 到底被安装到了哪个目录，方便你拷贝或者设置 PATH。

另外，Debug 和 Release 对应的路径会分别写在 OpenSSLTargets-debug.cmake 与 OpenSSLTargets-release.cmake 文件中，最终生成的主 targets 文件里再根据当前构建类型做选择。如果某次构建选了 Release，却一直提示无法解析外部符号，可以先回去检查是不是 config 阶段把 vcpkg 的 VCPKG_TARGET_TRIPLET 设成了不包含 Release 库的版本，或者自己手动改了 CMAKE_BUILD_TYPE 导致 CMake 去找一个不存在的 release 导入库。

3. 从零搭一个能吃上 OpenSSL 的 CMake 工程

理论知识说多了容易飘，接下来直接走一遍完整流程。我会用一个真实的 HTTPS 客户端小程序作为示范工程，目标是让它在 Windows + Visual Studio 2022 + 64 位环境下，通过 vcpkg 管理 OpenSSL，最后能编译出 exe 并成功发起 TLS 连接。

3.1 环境准备：安装 vcpkg 和 openssl 端口

第一步，把 vcpkg 克隆到本地。这里假设你放在 C:/dev/vcpkg：

bash复制cd C:/dev
git clone https://github.com/microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.bat

第二步，安装 OpenSSL。这里要明确指定 triplet，我建议先用动态库版本：

bash复制vcpkg install openssl:x64-windows

先解释一下为什么选择 x64-windows。这个 triplet 是 vcpkg 在 Windows 上最常用的默认动态库组合，编译出来的库文件同时包含 DLL 和配套的导入库。如果你不确定自己需要哪种，建议先从动态库开始，因为动态库在 MSVC 下默认和运行时模式兼容性最好，踩坑概率低。

安装完成后，可以到 C:/dev/vcpkg/installed/x64-windows/share/openssl/ 目录下确认 OpenSSLConfig.cmake 是否已经生成。这个目录结构就是我们前面讨论的所有内容的最终产物。

3.2 工程文件：一个最小但完整的测试工程

新建一个目录 openssl_demo，里面放一个源文件和一个 CMakeLists.txt。

先写主程序，内容很简单，只验证 TLS 上下文能正常创建即可：

cpp复制#include <openssl/ssl.h>
#include <iostream>

int main() {
    SSL_library_init();
    SSL_CTX* ctx = SSL_CTX_new(TLS_client_method());
    if (ctx == nullptr) {
        std::cerr << "create ssl ctx failed" << std::endl;
        return 1;
    }
    std::cout << "openssl ctx created" << std::endl;
    SSL_CTX_free(ctx);
    return 0;
}

再写 CMakeLists.txt：

cmake复制cmake_minimum_required(VERSION 3.15)
project(OpenSSL_Demo LANGUAGES CXX)

find_package(OpenSSL REQUIRED)

add_executable(openssl_demo main.cpp)
target_link_libraries(openssl_demo PRIVATE OpenSSL::SSL OpenSSL::Crypto)

这里的重点在于，我并没有写 include_directories(${OPENSSL_INCLUDE_DIR})，也没有手动把某个 .lib 文件的完整路径塞进 target_link_libraries。所有头文件目录、库路径、宏定义都由 OpenSSL::SSL 和 OpenSSL::Crypto 这两个导入目标内部携带，CMake 在生成构建系统时会自动展开。这也是很多开发者被 vcpkg 集成方式“惯”久了之后反而不太会手写 FindOpenSSL 相关代码的原因。

配置工程时，关键参数必须带上 toolchain：

bash复制cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake

执行成功后，CMake 会在输出里看到一行类似 Found OpenSSL 的信息。如果你想确认导入目标已经被正确加载，可以在 CMakeLists 里加上：

cmake复制if(TARGET OpenSSL::SSL)
    message(STATUS "OpenSSL::SSL target is available")
endif()

然后继续编译：

bash复制cmake --build build --config Release

如果一切正常，build/Release/openssl_demo.exe 会被生成。运行 exe，如果 Canvas 动态链接库没有被打进可执行文件目录，Windows 的 DLL 搜索规则会先找 exe 所在目录。所以在直接双击运行时，记得把 C:/dev/vcpkg/installed/x64-windows/bin/ 下对应的 libssl-3-x64.dll 和 libcrypto-3-x64.dll 复制到 exe 旁边，或者把该目录加进系统 PATH。

3.3 静态编译场景：triplet 和 toolchain 都不能随意省

有相当一部分桌面应用希望最终交付一个不需要依赖一堆 DLL 的单文件 exe，这时需要把 OpenSSL 静态编进程序。vcpkg 里可以选择：

bash复制vcpkg install openssl:x64-windows-static

对应 CMake 配置时，除了带 toolchain 还要显式指定目标 triplet：

bash复制cmake -S . -B build-static \
  -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake \
  -DVCPKG_TARGET_TRIPLET=x64-windows-static

很多人忽略第二步，以为安装端口时写了 triplet 就够了。但实际上 configure 阶段如果不告诉 CMake 要用哪个 triplet，vcpkg 的 toolchain 会使用默认值。如果你在同一台机器上既装过 x64-windows 又装过 x64-windows-static，CMake 很可能默认去匹配了动态库版本，导致发生“你想静态链接、CMake 却给了你 DLL 导入库”的错位。

静态库场景下最令人头疼的是编译参数不匹配。MSVC 中 /MD 和 /MT 有严格的运行时库约束，如果你的程序使用 /MT（静态运行时），而第三方静态库却是 /MD 模式编译的，链接时就会出现 LNK2038 这类 RuntimeLibrary mismatch 错误。

vcpkg 为了解决这个问题提供了几个不同排列的 triplet。刚开始用的时候可能被搞晕，但你只需要知道两条经验：

• x64-windows-static 大致对应“静态库 + 静态运行时”的搭配，适合最终交付物尽量不依赖 DLL 的场景。
• x64-windows-static-md 大致对应“静态库 + 动态运行时”的搭配，即库是静态的，但程序运行仍然借用系统的 vcruntime140.dll 这类运行时组件。

具体用哪个取决于你的交付策略和企业内部的基础镜像环境。常见做法是先编译一个接入 OpenSSL 的静态库，然后打进插件或模块中，这时需要看宿主程序已经链接了哪种运行时，尽量保持一致，否则又会跳出一堆链接错误。

如果你在 MSBuild 式的 Visual Studio 工程里使用 vcpkg，选择方式是在 CMakeSettings.json 或 VS 的项目属性里设置 VCPKG_TARGET_TRIPLET，而不是在命令行里随手写。VS 的 CMake 集成在配置时会自动拼接 toolchain 参数，变量设置面板里填写的 triplet 最终会传递到 CMake 的 configure 阶段，不过前提是你没有在命令行里把变量写死，否则两边会产生冲突。

4. 常见问题与排查技巧实录

下面这组问题是从我日常排查和工程咨询中挑出来的高频案例，也覆盖了不少开发者搜索时的痛点。把它们按现象、原因、解决方式分类列出来，之后碰到类似的报错可以先对照这张表再动手，能省不少时间。

4.1 最容易被误判的“找不到包”问题

先说最高的报错。很多人一看到“Could not find a package configuration file provided by OpenSSL”就会跑回 vcpkg 目录，把所有版本重新装一遍，结果当然没用。首先要理解这句话的完整含义：CMake 找的并不是“OpenSSL 库”，而是 OpenSSLConfig.cmake 这个文件。因此排查顺序是：

第一步，确认包确实装了。到 C:/dev/vcpkg/installed/x64-windows/share/openssl/ 里看一眼有没有 OpenSSLConfig.cmake。没有说明安装阶段出了问题，或者安装的是其他 triplet，目录路径里的 x64-windows 与你当前 configure 阶段指定的不一致。

第二步，确认 CMake 的搜索路径里真的包含了 installed 根路径。最简单的方法是临时在 CMakeLists 开头打印：

cmake复制message(STATUS "CMAKE_PREFIX_PATH = ${CMAKE_PREFIX_PATH}")
message(STATUS "VCPKG_TARGET_TRIPLET = ${VCPKG_TARGET_TRIPLET}")

如果你打印出来的 CMAKE_PREFIX_PATH 里没有 C:/dev/vcpkg/installed/x64-windows，就说明 vcpkg 的 toolchain 在配置时没有被加载。此时审视一下是不是 CMakeLists 开头写了什么 set(CMAKE_TOOLCHAIN_FILE ...) 并覆盖了外层命令行的变量，或者 CMakeLists 里在 project() 之前就 unset 了它。toolchain 的加载时机是在 project() 阶段之前，一旦错过，后面补设通常不会生效，建议最老实的办法是在命令行或 IDE 项目设置里指定。

第三步，确认没有残留的旧变量把搜索过程带到奇怪路径。例如 OPENSSL_ROOT_DIR 被手动设置成了某个不存在的目录，会影响查找结果。把这类变量清掉再 configure 一次，往往就恢复正常。

4.2 编译过了但链接不上，别急着重新编译整个 OpenSSL

如果你的程序能正确 include 到 openssl/ssl.h，却在最后链接阶段报一堆 unresolved external symbol，这属于另一个层级的问题。

“头文件找得到”说明导入目标的 INTERFACE_INCLUDE_DIRECTORIES 路径正确；链接报错则说明对应函数在库文件里不存在，或者你链接的库根本不是你当前编译指令对应的版本。比如 Debug 版程序去链接 Release 版 OpenSSL 导入库，在 MSVC 上很常见，因为两边的运行库名一样，但实际实现可能不同，某些符号在 Debug 的 ssleay32.lib / libssl.lib 上找不到。

此时你要去打开 OpenSSLTargets-debug.cmake 和 OpenSSLTargets-release.cmake，查看对应配置下的 IMPORTED_IMPLIB_DEBUG 与 IMPORTED_IMPLIB_RELEASE。如果发现 Release 文件中的库路径指向 installed/x64-windows/lib/libssl.lib，而 Debug 文件中的库路径指向 installed/x64-windows/debug/lib/libssl.lib，那就说明 vcpkg 为你准备了 Debug 和 Release 两套库。默认情况下，CMake 会按你当前构建类型自动选。如果选错，就要检查 configure 时是不是缺了 --config Release，或者 VS 的生成类型和 CMake 预设不一致。

还有一种容易被忽略的情况：同一个 exe 里混用了 MSVC 编译的 OpenSSL 和 MinGW 编译的 OpenSSL。由于编译器重命名规则、调用约定、运行时库差异都很大，这种问题几乎无解。更靠谱的做法是回到 vcpkg 安装阶段，用和主工程完全一致的编译链重新安装端口。vcpkg 的三元组设计本身也在强制你做这件事：需要区分编译器、架构、运行时。使用不匹配三元组装出来的库，在 CMake 层面也许能混过去，到链接阶段就会被 LLVM 或 MSVC 的“底层不兼容”全盘暴露出来。

4.3 用 debug-find 参数逼出 CMake 的内心活动

最后分享一个我最近很依赖的调试技巧。CMake 3.17 以后提供了一个很实用的参数，可以打印出 find_package 在查找包时到底看了哪些路径、为什么接受或拒绝。以 OpenSSL 为例，在 configure 命令里加：

bash复制cmake -S . -B build \
  -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake \
  --debug-find-pkg=OpenSSL

CMake 会输出类似这样的一大段日志：

text复制CMake Debug Log at CMakeLists.txt:4 (find_package):
  find_package considered the following paths for OpenSSLConfig.cmake:
    C:/dev/vcpkg/installed/x64-windows/share/openssl/OpenSSLConfig.cmake
    ...
  The file was found and loaded.

当你把 CMAKE_PREFIX_PATH、CMAKE_SYSTEM_PREFIX_PATH、CMAKE_FIND_ROOT_PATH 这些变量的影响搞不清楚时，这个工具能把黑盒变成白盒。我尤其建议在“为什么我明明传了路径却还是没找到包”这种情形下使用，远比盲改 CMakeLists 快。

另一个实用技巧是在 CMake GUI 或命令行里手动打印库文件路径：

bash复制cmake -LAH -N build | grep -i openssl

不过这个命令只有在 CMakeCache 已经生成时才有意义。如果还没 configure 成功，建议还是先走 debug-find 参数看全貌。

4.4 什么时候需要手动改 OpenSSLConfig.cmake

说实话，绝大多数项目都不应该手动去改 vcpkg 安装目录里的 OpenSSLConfig.cmake。每次升级端口或重装 vcpkg，改动都会被覆盖，维护成本极高。但你可能会遇到一种例外：某些老项目仍然通过 OPENSSL_ROOT_DIR 和 OPENSSL_CRYPTO_LIBRARY 这几个变量来引用库，而这些变量在 config 模式下只会被设置为相对路径，不满足老代码的预期。这时与其在工程里到处打补丁，不如看仔细之后写几行兼容逻辑：

cmake复制if(VCPKG_TARGET_TRIPLET MATCHES "windows-static")
    set(OPENSSL_USE_STATIC_LIBS ON)
endif()

有的人会直接在 config 文件里写死这个变量，但我不建议。原因很简单：变量本身属于“消费方”的配置决策，不该反向写进“提供方”的文件里，否则换一个项目引用同一个 vcpkg 环境时，会被这份被改过的 config 影响到。更优雅的做法是在自己的 CMakeLists 里，在 find_package 之前显式声明：

cmake复制set(OPENSSL_USE_STATIC_LIBS ON)
find_package(OpenSSL REQUIRED)

如果有同事接手你的工程，看到这行就能知道你选的是静态方案。把这个选择放在工程代码里而不是藏在第三方包安装目录里，对可维护性的帮助非常明显。

5. 从 OpenSSL 这件事看 vcpkg 的整体设计

聊了这么多 OpenSSLConfig.cmake 的具体内容，最后再多说一层我个人的体会。

vcpkg 希望达到的效果，本质上是把“库怎么装”“装到哪”“怎么给 CMake 用”三个问题标准化下来。OpenSSL 作为其中依赖最复杂的库之一，config 文件的格式和查找逻辑天然就比很多纯 header-only 的库严谨得多。当你把 OpenSSL 的这一套机制吃透之后，再看 vcpkg 里其他库提供的 config 文件，会发现大多是同一个模子刻出来的。也许文件里的目标名变了，变量前缀变了，但框架基本相同。

因此，把这个文件拆开看一遍，价值并不局限于 OpenSSL。你会知道 CMake package 查找是“按文件名索引”的，会知道导入目标内部能携带多少信息，也知道排查链接问题时该从哪个文件入手。这套经验可以平移到 Boost、libcurl、sqlite3 等几乎所有 vcpkg 管理的库上。

再分享一个最后的小建议：以后你的工程抛出和第三方库相关的 CMake 错误时，不要一上来就怀疑 vcpkg 装坏了。先找到对应包在 installed/<triplet>/share/<包名>/ 目录下的 config 文件，从入口文件开始读，按“文件是否存在、路径是否在搜索范围内、目标定义是否完整、组件检查是否通过”的顺序排查。绝大多数问题都能在这一条路径上被定位出来。这种排查方式，比反复删 build 目录、重装依赖包要靠谱得多。