CentOS 10下Docker部署Redis全流程指南
2026/10/24 9:16:33
简介：面向使用 OpenSceneGraph 与 osgEarth 进行三维地球、GIS 可视化开发的 C++ 工程师，这份预编译三方库省去了自行搭建依赖链的大量时间。资源针对 OSG3.6.5 与 osgEarth2.10 的编译需求整理，基于 Visual Studio 2019 完成 64 位预编译，可直接对接工程配置，降低因库版本不匹配、编译参数差异导致的链接错误风险，适合熟悉 CMake 与 VS 工程配置的中级开发者。压缩包约 137.76MB，共约 2000 个文件，以 1351 个 h 头文件、56 个 lib 静态与导入库、4 个 dll 动态库为核心，另含 32 个 cmake 配置脚本、28 个 inc 与 22 个 c 源文件、14 个 proto 与 14 个 hpp，以及 html 文档和时区数据文件，覆盖头文件声明、链接库、构建脚本与说明文档四类用途。已有 626 人学习下载。解压后按 include、lib 等目录即可接入现有解决方案，配合 CMake 查找模块快速定位依赖，便于集中排查版本冲突与路径配置问题。
1. 预编译 3rdParty 不是万能药：它解决的是 OSG3.6.5 在 VS2019 下最脏的那段依赖
VS2019 下编 OSG3.6.5 和 osgEarth，最烦的往往不是写 CMakeLists，而是 zlib、libpng、curl、GDAL、PROJ、SQLite 这些第三方库一个个找源码、对工具集、改工程、补 DLL。这个3rdParty.zip的价值就在这儿：它把 OSG3.6.5 和 osgEarth 常用的三方依赖按预编译形式备好，省掉从零编依赖的那一下午。它适合手里已有 OSG/osgEarth 源码、用 VS2019 做 x64 构建、又不想在依赖编译上反复填坑的人。但它不是“丢进去就完事”的万能药，ABI、Debug/Release、VC16 工具集对不上，照样翻车。
2. 拆包先对 ABI：3rdParty.zip 的目录、VC16 工具集与 x64/Debug 组合核对
2.1 包内目录的典型布局与先核对项
预编译三方库包最常见的布局是按“头文件、导入库、运行时 DLL、CMake 配置”拆开。拿到包先别急着解压到源码目录，先看顶层有没有include、lib、bin、share、cmake这几类目录，再看lib下面是不是按x64、Win32、Debug、Release继续分层。很多链接错误不是 CMake 写错，而是把 Win32 的.lib喂给了 x64 工程，或者把 Release 的库塞进了 Debug 配置。
| 目录/文件 | 典型用途 | 先核对什么 |
|---|---|---|
include/ | 三方库头文件 | 版本头文件是否与 OSG/osgEarth 源码要求一致 |
lib/ | .lib导入库 | 是否分x64/Win32、Debug/Release |
bin/ | 运行时 DLL | 是否有zlib1.dll、gdal*.dll、proj*.dll等 |
share/ | GDAL/PROJ 数据 | 是否有gdal-data、proj.db |
cmake/ | Find 模块或配置 | 是否提供FindXXX.cmake或XXXConfig.cmake |
提示：VS2019 的工具集是 VC16，预编译包如果按 VC15、VC14 编的，不要硬链。MSVC 二进制兼容有边界，Debug/Release 的 CRT 也不一样，混用就是 LNK2019 和运行时崩溃的温床。
2.2 解压路径与目录命名：把空格和中文先处理掉
我一般把三方库放到一个短路径下，比如D:/dev/osg-deps/3rdparty-vc16-x64，源码放D:/dev/osg-src/OpenSceneGraph-3.6.5。路径里不要有空格、中文、括号，CMake 和部分老式 Find 模块对空格的处理很玄学。解压时保留包内层级，不要把所有bin和lib拍平到一个目录，否则后面 Debug/Release 切换会很难受。
# 创建短路径依赖目录，避免空格和中文 New-Item -ItemType Directory -Force -Path D:\dev\osg-deps\3rdparty-vc16-x64 # 解压 3rdParty.zip 到该目录，保留包内层级 Expand-Archive -Path D:\downloads\3rdParty.zip -DestinationPath D:\dev\osg-deps\3rdparty-vc16-x64 -Force # 看顶层结构，确认 include/lib/bin/share 是否存在 Get-ChildItem D:\dev\osg-deps\3rdparty-vc16-x64这段命令只做三件事：建目录、解压、看结构。-Force会覆盖同名文件，第二次解压时别把手工补的 DLL 覆盖掉。DestinationPath不要直接指向 OSG 源码根目录，预编译包和源码混在一起后，CMake 缓存和清理都会变脏。解压完先看lib下有没有x64或Debug子目录，没有的话再决定是不是把整个包当成单一配置使用。
2.3 用 CMake 探测三方库：先跑一个最小 find_package 验证
不要一上来就配 OSG 全量工程。先写一个最小CMakeLists.txt，只查 zlib、png、curl 这类高频依赖，确认 CMake 能在你指定的前缀路径下找到头文件和库。这个步骤能把“路径不对”和“库本身不对”分开，省得在 OSG 的大工程里看几百行日志。
cmake_minimum_required(VERSION 3.16) project(check_3rdparty LANGUAGES C CXX) # 让 CMake 优先在预编译三方库目录下找依赖 list(PREPEND CMAKE_PREFIX_PATH "D:/dev/osg-deps/3rdparty-vc16-x64") # 如果包内带 Find 模块，把 cmake 目录加进模块搜索路径 list(APPEND CMAKE_MODULE_PATH "D:/dev/osg-deps/3rdparty-vc16-x64/cmake") find_package(ZLIB REQUIRED) find_package(PNG REQUIRED) find_package(CURL REQUIRED) message(STATUS "ZLIB_INCLUDE_DIR=${ZLIB_INCLUDE_DIR}") message(STATUS "ZLIB_LIBRARY=${ZLIB_LIBRARY}") message(STATUS "PNG_LIBRARY=${PNG_LIBRARY}") message(STATUS "CURL_LIBRARY=${CURL_LIBRARY}")CMAKE_PREFIX_PATH是前缀路径，不是单个库路径，CMake 会按<prefix>/include、<prefix>/lib去找。CMAKE_MODULE_PATH只对包内自带的FindXXX.cmake有用，没有就别硬加。find_package(... REQUIRED)一旦失败会直接停，正好用来判断依赖是否齐。message(STATUS ...)打印出来的变量值要逐条看，尤其注意.lib路径里有没有Debug或Release字样。
:: 用 VS2019 x64 生成器配置最小探测工程 cmake -S D:\dev\check-3rdparty -B D:\dev\check-3rdparty\build -G "Visual Studio 16 2019" -A x64 cmake --build D:\dev\check-3rdparty\build --config Release-S是源码目录，-B是构建目录，-G指定 VS2019 生成器，-A x64决定目标架构。这里不写-A时 CMake 可能默认 Win32，后面链接 x64 库会报机器类型冲突。最小工程能过，再进 OSG 主工程；最小工程过不了，先查包内目录和CMAKE_PREFIX_PATH，别去改 OSG 的 CMake 参数。
3. 把 OSG3.6.5 编出来：CMake 生成器、前缀路径与 Release/Debug 双配置
3.1 生成器选择：Visual Studio 16 2019 与 x64 必须一次定死
OSG3.6.5 在 VS2019 下建议用 “Visual Studio 16 2019” 生成器，架构一次定成 x64，不要在同一个构建目录里来回切 Win32 和 x64。CMake 缓存会记住第一次的生成器和架构，后面改-A经常出现“配置看着变了，链接还是旧架构”的假象。我的习惯是每个配置一个独立构建目录：build-vs2019-x64-release和build-vs2019-x64-debug，互不污染。
:: OSG 源码目录和构建目录分开，Release 单独一个构建树 set OSG_SRC=D:\dev\osg-src\OpenSceneGraph-3.6.5 set OSG_BUILD=D:\dev\osg-build\vs2019-x64-release set OSG_INSTALL=D:\dev\osg-install\vs2019-x64-release set DEPS=D:\dev\osg-deps\3rdparty-vc16-x64 cmake -S %OSG_SRC% -B %OSG_BUILD% ^ -G "Visual Studio 16 2019" -A x64 ^ -DCMAKE_PREFIX_PATH="%DEPS%" ^ -DCMAKE_INSTALL_PREFIX="%OSG_INSTALL%" ^ -DBUILD_OSG_EXAMPLES=OFF ^ -DOPENGL_PROFILE=GL3CMAKE_PREFIX_PATH指向三方库根目录，CMake 会从这里找include和lib。CMAKE_INSTALL_PREFIX是INSTALL目标的目标目录，后面 osgEarth 要靠它找 OSG。BUILD_OSG_EXAMPLES=OFF先关示例，减少首次构建的变量。OPENGL_PROFILE=GL3是常见选择，老项目如果固定用固定管线，按项目要求改，不要盲目照抄。
3.2 关键 CMake 变量：把 3rdParty 的 include 和 lib 喂给 OSG
OSG 的依赖查找大多走 CMake 的FindXXX模块，CMAKE_PREFIX_PATH给对了，ZLIB_LIBRARY、PNG_LIBRARY这些变量一般能自动落到预编译包上。怕它找系统库，可以在配置日志里搜Found ZLIB、Found PNG，看路径是不是D:/dev/osg-deps/...。如果包内提供了自定义 Find 模块，再把CMAKE_MODULE_PATH加进去；没有就别加，免得模块版本和 OSG 源码里的查找逻辑打架。
# 可选：在 OSG 的 CMake 配置阶段强制指定关键库路径 # 路径按包内实际 lib 子目录调整，不要照抄不存在的文件名 set(ZLIB_INCLUDE_DIR "D:/dev/osg-deps/3rdparty-vc16-x64/include") set(ZLIB_LIBRARY "D:/dev/osg-deps/3rdparty-vc16-x64/lib/x64/zlib.lib") set(PNG_LIBRARY "D:/dev/osg-deps/3rdparty-vc16-x64/lib/x64/libpng16.lib")这种硬指定适合“CMake 找到了系统里的旧库”这种场景，不适合当默认写法。ZLIB_LIBRARY必须指向真实存在的.lib，文件名按包内实际文件写，不要猜。Debug 配置下如果包内提供zlibd.lib或带d后缀的库，要换到 Debug 路径；没有 Debug 库就统一用 Release 依赖编 Release，别硬混。
3.3 编译与安装：Release 先跑通，再补 Debug
首次构建先跑 Release，目标选INSTALL，让头文件、库、DLL 一次性落到安装目录。构建日志里重点看链接阶段有没有LNK2019、LNK2038，前者多半是库没链上，后者多半是 CRT 或架构不一致。--parallel可以加快速度，但内存小的机器别开太大，OSG 的编译单元不算少。
:: Release 构建并安装，日志同时写文件方便回看 cmake --build %OSG_BUILD% --config Release --target INSTALL --parallel 8 > %OSG_BUILD%\build-release.log 2>&1 :: 检查安装目录下是否出现 include、lib、bin dir %OSG_INSTALL%--config Release对应 VS 的多配置生成器，--target INSTALL才会执行安装规则，只 buildALL_BUILD不会把文件收口到CMAKE_INSTALL_PREFIX。--parallel 8按 CPU 核数调，报错先看日志末尾。安装完检查bin里有没有osg*.dll，lib里有没有osg*.lib，include里有没有osg/Version这类头文件。
3.4 验证 OSG 是否真的链到了三方库：用 osgversion 和 dumpbin
编译通过不代表运行时依赖就齐。先跑osgversion看版本和插件路径，再用dumpbin /dependents看osgDB.dll到底依赖哪些 DLL。如果它依赖的zlib1.dll、libpng16.dll不在bin或PATH里，后面跑 osgEarth 一样会挂。这个检查比等到程序启动报错再回头找要省事。
:: 查看 osgDB.dll 的运行时依赖，确认三方 DLL 名称 dumpbin /dependents %OSG_INSTALL%\bin\osgDB.dll :: 运行 osgversion，确认 OSG 自身能启动 set PATH=%OSG_INSTALL%\bin;%DEPS%\bin;%PATH% osgversiondumpbin要在 VS 开发者命令行里跑，普通 cmd 可能找不到。set PATH只对当前终端有效，适合临时验证；长期使用建议把依赖bin写进系统或项目启动脚本。osgversion能跑只说明 OSG 核心动态库能加载，不代表所有插件和三方库都正常，后面还要用实际数据文件验证。
| 配置 | 库目录关注点 | 运行时目录关注点 | 常见误用 |
|---|---|---|---|
| Release x64 | lib/x64下 Release.lib | bin下 Release DLL | 把 Debug.lib链进 Release |
| Debug x64 | 是否有d后缀 Debug.lib | 是否有对应 Debug DLL | 用 Release DLL 跑 Debug |
| 安装目录 | lib、include齐全 | bin可执行 | 只 build 不 install |
4. 再接 osgEarth：GDAL/PROJ/CURL 的传递依赖与运行时 DLL 收口
4.1 osgEarth 的 CMake 入口：先让 find_package(OSG) 找到刚装的 OSG
osgEarth 的配置第一步不是找三方库，而是找 OSG。把OSG_DIR指到 OSG 安装目录下的lib/cmake/osg或包含osgConfig.cmake的目录，再把CMAKE_PREFIX_PATH同时指向 OSG 安装目录和 3rdParty 根目录。两个前缀都要有，缺一个就会出现“OSG 找到了，GDAL 找不到”的半吊子状态。
:: osgEarth 单独构建树，前缀同时包含 OSG 安装目录和 3rdParty set OSGEARTH_SRC=D:\dev\osg-src\osgearth set OSGEARTH_BUILD=D:\dev\osgearth-build\vs2019-x64-release set OSGEARTH_INSTALL=D:\dev\osgearth-install\vs2019-x64-release cmake -S %OSGEARTH_SRC% -B %OSGEARTH_BUILD% ^ -G "Visual Studio 16 2019" -A x64 ^ -DCMAKE_PREFIX_PATH="%OSG_INSTALL%;%DEPS%" ^ -DOSG_DIR="%OSG_INSTALL%\lib\cmake\osg" ^ -DCMAKE_INSTALL_PREFIX="%OSGEARTH_INSTALL%" ^ -DBUILD_OSGEARTH_EXAMPLES=OFFCMAKE_PREFIX_PATH里用分号分隔多个前缀，Windows 下不要用逗号。OSG_DIR指向 OSG 的 CMake 配置目录，路径按实际安装结果调整。BUILD_OSGEARTH_EXAMPLES=OFF先关示例，等核心库跑通再开。配置日志里要看到Found OSG的路径是D:/dev/osg-install/...，不是系统里别的 OSG。
4.2 GDAL/PROJ 数据目录与运行时 DLL：编译期能找到不等于运行期能跑
osgEarth 读影像、高程、矢量时经常走 GDAL，GDAL 又依赖 PROJ 做坐标转换。编译期 CMake 只关心.lib和头文件，运行期还要gdal-data、proj.db和一堆 DLL。预编译包里的share目录如果有这些数据，启动脚本里把GDAL_DATA、PROJ_LIB指过去；没有的话，运行时会报“找不到 proj.db”或坐标转换失败。
:: 运行时环境：PATH 收口 OSG、osgEarth、3rdParty 的 bin set PATH=%OSGEARTH_INSTALL%\bin;%OSG_INSTALL%\bin;%DEPS%\bin;%PATH% :: 数据目录按包内 share 实际子目录调整 set GDAL_DATA=%DEPS%\share\gdal set PROJ_LIB=%DEPS%\share\proj :: 启动一个 osgEarth 示例或自己的程序，观察控制台输出 osgearth_versionPATH的顺序决定 DLL 命中谁，项目自己的bin放前面，避免系统目录里的旧 DLL 抢先。GDAL_DATA指向gdal-data的父目录或实际数据目录，按包内结构写。PROJ_LIB要能找到proj.db，找不到时 osgEarth 可能不崩，但坐标转换结果会错，这种错误比崩溃更难查。
4.3 常见构建开关与插件裁剪：先最小可用，再加功能
osgEarth 的 CMake 选项不少，第一次构建不要全开。示例、测试、某些插件依赖额外三方库，开多了容易把“缺库”和“代码问题”混在一起。先让核心库和常用插件过，再按项目需要补。下表是常见开关的处理思路，具体选项名以源码里的CMakeLists.txt为准，不同分支会有差异。
| 选项/目标 | 作用 | 首次构建建议 |
|---|---|---|
BUILD_OSGEARTH_EXAMPLES | 编译示例程序 | 先 OFF，核心库过了再开 |
BUILD_OSGEARTH_TESTS | 编译测试 | 先 OFF，避免测试依赖干扰 |
| 插件目标 | 按数据源启用 | 先只开项目实际用的 |
CMAKE_INSTALL_PREFIX | 安装目录 | 独立目录，不和 OSG 混装 |
裁剪插件时别只看“能不能编过”，还要看运行时加载。插件 DLL 放在bin/osgPlugins-*或 osgEarth 的插件目录下，路径不对时程序不会报编译错误，只在读文件时提示找不到插件。首次构建完，拿一个最小地球文件或项目自带数据跑一遍，确认插件真的被加载。
4.4 安装与运行时目录拼装：把 bin 收口到一个目录
调试阶段最省事的做法是把 OSG、osgEarth、3rdParty 的bin收口到一个运行目录，启动脚本只认这一个PATH。这样不会出现“开发机能跑、换台机器就缺 DLL”的情况。复制时只复制三方 DLL 和项目 DLL，不要复制系统 DLL，系统库跟着 Windows 走。
:: 建一个运行目录，把三类 bin 的 DLL 收口进去 set RUNDIR=D:\dev\osg-runtime\bin mkdir %RUNDIR% xcopy /Y /D %OSG_INSTALL%\bin\*.dll %RUNDIR%\ xcopy /Y /D %OSGEARTH_INSTALL%\bin\*.dll %RUNDIR%\ xcopy /Y /D %DEPS%\bin\*.dll %RUNDIR%\xcopy /D只复制源比目标新的文件，反复执行不会重复覆盖。/Y跳过覆盖确认，适合脚本。收口目录不要放进源码仓库，DLL 体积大且和构建配置绑定。Debug 和 Release 的 DLL 不要混在同一个运行目录，分别建bin-debug和bin-release，否则调试时加载错版本，表现是随机崩溃或断言失败。
| DLL 来源 | 典型文件 | 放置位置 |
|---|---|---|
| OSG 安装目录 | osg*.dll、osgDB.dll | 运行目录bin |
| osgEarth 安装目录 | osgEarth*.dll、插件 DLL | 运行目录bin及插件子目录 |
| 3rdParty 包 | zlib1.dll、libpng16.dll、gdal*.dll、proj*.dll | 运行目录bin |
| 数据文件 | proj.db、gdal-data | 由PROJ_LIB、GDAL_DATA指向 |
5. 避坑与排查：预编译三方库在 VS2019 里最容易翻车的五处
5.1 现象：CMake 找到了头文件，链接却报 LNK2019
现象是配置阶段日志正常，Found ZLIB、Found PNG都打出来了，一到链接就报某个符号未解析。原因通常是.lib架构不对、Debug/Release 混用，或者 CRT 运行库不一致。解决顺序是先看 CMake 打印的库路径是不是x64，再用dumpbin /headers看库的机器类型，最后核对工程运行库设置。不要一上来改源码，先把库换对。
:: 看 .lib 的机器类型，x64 应显示 machine (x64) dumpbin /headers D:\dev\osg-deps\3rdparty-vc16-x64\lib\x64\zlib.lib | findstr /i "machine"dumpbin /headers只读文件头，不执行代码。findstr过滤出 machine 行，x64 库不应出现 x86。Debug 配置下如果只有 Release 库，先把整个构建切到 Release 验证，再决定是否补 Debug 依赖。LNK2038 这类“运行库不匹配”的报错，重点看/MT和/MD是否和预编译库一致。
5.2 现象：运行时报找不到 zlib1.dll / gdalxxx.dll
程序启动直接弹“找不到 zlib1.dll”，或者加载插件时提示某个 GDAL DLL 缺失。原因是PATH没包含 3rdParty 的bin，或者只把.lib链上了，运行时 DLL 没跟着走。解决不是把 DLL 散落到系统目录，而是把运行目录收口，启动脚本里显式设置PATH。调完之后用dumpbin /dependents反查还缺什么。
:: 反查 osgEarth 核心 DLL 的依赖，确认缺哪个三方 DLL dumpbin /dependents %OSGEARTH_INSTALL%\bin\osgEarth.dlldumpbin /dependents列出直接依赖，不递归。缺的 DLL 可能不在列表里但被插件间接依赖，所以插件 DLL 也要查。把缺的 DLL 从 3rdParty 的bin复制到运行目录，再启动。不要从网上随便抓同名 DLL 替换，版本不匹配会导致更隐蔽的崩溃。
5.3 现象：osgEarth 启动报 PROJ 数据库错误
控制台出现proj.db找不到、坐标转换失败，或者读某些矢量数据时提示投影初始化失败。原因多半是PROJ_LIB没设，或者指向了错误版本的数据目录。预编译包里的proj.db版本要和proj.dll对得上，拿旧数据配新库同样会出错。解决是把PROJ_LIB指到包内实际share/proj，并确认proj.db存在。
:: 确认 proj.db 是否存在，路径按包内实际结构改 dir D:\dev\osg-deps\3rdparty-vc16-x64\share\proj\proj.db :: 设置后再启动程序 set PROJ_LIB=D:\dev\osg-deps\3rdparty-vc16-x64\share\projdir能看到文件再设环境变量，别设一个空目录。GDAL_DATA同理，指向gdal-data的父目录或实际数据目录。环境变量只在当前终端有效，IDE 里调试要在项目调试属性里再加一遍，否则命令行能跑、VS 里跑不了。
5.4 现象：VS2019 生成器选成 Win32，三方库是 x64
配置时没写-A x64，CMake 默认生成 Win32 工程，链接 x64 的.lib时报机器类型冲突。更麻烦的是构建目录已经缓存了 Win32，后面再加-A x64也不一定生效。解决是删掉构建目录重新配置，或者新建一个独立构建树。CMake 缓存不是后悔药，架构错了就清。
:: 删除构建目录后重新用 x64 配置，别在旧缓存上硬改 rmdir /S /Q D:\dev\osg-build\vs2019-x64-release cmake -S D:\dev\osg-src\OpenSceneGraph-3.6.5 -B D:\dev\osg-build\vs2019-x64-release -G "Visual Studio 16 2019" -A x64rmdir /S /Q会连缓存一起删，执行前确认路径是构建目录，不是源码目录。重新配置后看日志里的CMAKE_GENERATOR_PLATFORM是不是x64。如果团队里有人用 Win32，另建一个build-vs2019-win32，不要共用一个构建树。
5.5 现象：CMake 缓存污染，改了路径仍找旧库
明明把CMAKE_PREFIX_PATH改到了新解压目录，配置日志里还是旧路径。原因是CMakeCache.txt里已经缓存了ZLIB_LIBRARY、PNG_LIBRARY等变量，命令行传新前缀不一定覆盖旧缓存。解决是清缓存重配，或者在 CMake GUI 里把相关变量删掉。血泪经验是：换三方库目录后，第一件事就是清构建树。
:: 查缓存里实际记录的库路径 findstr /i "ZLIB_LIBRARY PNG_LIBRARY CURL_LIBRARY" D:\dev\osg-build\vs2019-x64-release\CMakeCache.txtfindstr能快速定位缓存变量，看到的路径如果还是旧目录，就清缓存。不要手动编辑CMakeCache.txt，格式错了更难查。清完重新跑配置命令，日志里再确认一次路径。这个动作花不了一分钟，能省掉半天的“为什么改了没用”。
6. 进阶体检：用脚本把 3rdParty 依赖、DLL 与 CMake 缓存一次查清
构建次数多了，我会在每次配置前跑一个很小的体检脚本，只查三件事：三方库根目录是否存在、关键头文件和库是否落在预期子目录、运行目录里的 DLL 是否齐全。这个脚本不替代 CMake，只用来把“路径写错”这类低级问题挡在配置之前。下面这个 Python 片段按需改路径和文件名，不要照抄不存在的库名。
from pathlib import Path deps = Path(r"D:\dev\osg-deps\3rdparty-vc16-x64") checks = { "include": deps / "include", "lib_x64": deps / "lib" / "x64", "bin": deps / "bin", "proj_db": deps / "share" / "proj" / "proj.db", } for name, path in checks.items(): print(f"{name}: {'OK' if path.exists() else 'MISSING'} -> {path}") # 只做存在性检查，不判断版本；版本仍以 CMake 配置日志为准脚本里的Path用原始字符串避免反斜杠转义，checks字典的键只是标签，值才是实际路径。exists()只判断存在，不判断架构和版本，所以它过了不代表一定能链上，但没过就先别配 CMake。运行目录的 DLL 检查可以再加一段遍历bin下*.dll，和dumpbin的输出对照。从那以后我每次换三方库目录、切 Debug/Release、换 VS 生成器，都强制先跑一遍体检和最小find_package，再进主工程。希望帮到你。
本文还有配套的精品资源，点击获取