简介面向Visual Studio 2022 64位开发环境的 osgEarth 3.4.0基于OSG 3.6.5自编译版为需要在Windows平台构建三维GIS应用的C开发者提供即拿即用的编译产物。压缩包共2000个文件、约483.88MB主体为1948个.h头文件和47个.hpp头文件包含完整API声明另附txt、pdf、md说明文档及c源文件便于查阅与二次开发。内含Debug与Release两种配置的exe、dll、lib及pdb调试信息可直接链接到项目中既能断点调试又可做性能优化。库基于GL2与OSG 3.6.5构建覆盖场景管理、地形渲染、纹理映射等常用功能相当于为OSG扩展了三维地图数据可视化能力。已有1249人学习下载适合快速集成osgEarth到既有工程的中高级开发者省去自行用vcpkg编译配置的繁琐环节。1. 为什么 VS2022 下还要自己编译 osgEarth 3.4.0 OSG 3.6.5做三维 GIS 和数字孪生的人大多绕不开 osgEarth。网上能下到的自编译版要么只带 Release 和一堆缺失的 PDB要么是 32 位要么绑的 OSG 版本和你手头代码对不上。最难受的是你怀疑某个 driver 的行为不对想断点进 osgEarth 源码看一眼结果符号文件是空的完全没法调。我自己就是因为这个原因才开始在 VS2022 下按 64 位 Debug Release 重新编译 OSG 3.6.5 和 osgEarth 3.4.0。这个组合在 3.x 时代是经过大量项目验证的配对OSG 3.6.5 的插件机制和 osgEarth 3.4.0 的 MapNode 接口互相匹配。自己编译一次能拿到干净的 Debug/Release 两套库、可调试的 PDB、以及完全可控的第三方依赖。下面这一套流程照着走完你也能产出一份可以反复复用的 osgEarth 3.4.0 OSG 3.6.5 VS2022 64位自编译产物。2. 编译前的底子VS2022 64 位环境、CMake 生成器与依赖目录规划2.1 VS2022 环境社区版免费C 组件和 CMake 工具一次勾全工欲善其事先搞定编译器。网上搜 vs2022 下载安装教程能找到一堆图文但很多教程没说清楚编译 OSG 这种老牌 C 项目只需要 VS2022 社区版免费不需要产品密钥专业版和企业版的功能在这里用不上。安装时在“单个组件”里必须勾三样使用 C 的桌面开发、适用于 Windows 的 C CMake 工具、Windows 10/11 SDK。缺了第三个,后面编译 osgEarth 时会出现一堆 windows.h 相关的间接报错。安装完成后能省很多事的是安装好 VS2022 离线安装包这在隔离网环境里几乎是必经之路。常见做法是用vs_BuildTools.exe --layout先拉一份离线缓存装到目标机器上时再加 C 组件不然现场等下载能等半小时。装好后打开“开始菜单 - Visual Studio 2022 - Developer PowerShell”验证一下环境cl cmake --version如果cl提示不是内部或外部命令说明 C 工具集没装全回到 VS Installer 补勾“使用 C 的桌面开发”。cmake 自带的是新版本至少 3.20 以上足够生成 VS2022 工程。确认这两条命令能跑环境这部分就过关了。2.2 64 位与 Debug/Release 双库为什么目录要按配置类型分开Windows 下 MSVC 有个约定Debug 库在库名上加dRelease 不加。OSG 编译出来就是osgCored.lib和osgCore.libDLL 则分别进到bin/Debug和bin/Release。很多人第一次编译安装前缀统一指到D:/3rdparty/osg-3.6.5Debug 装完装 Release结果bin目录里同一份 DLL 被反复覆盖到最后只有最后一版能在运行时被找到排查起来相当难受。我一般会直接在 3rdparty 根目录下建两个互不干扰的安装位置比如用途路径OSG Debug 库D:/3rdparty/osg-3.6.5-debugOSG Release 库D:/3rdparty/osg-3.6.5-releaseosgEarth Debug 库D:/3rdparty/osgearth-3.4.0-debugosgEarth Release 库D:/3rdparty/osgearth-3.4.0-release第三方依赖也放在同级目录D:/3rdparty/osg-3rdparty下里面按 include / lib / bin 展开。这样给 OSG 和 osgEarth 传CMAKE_PREFIX_PATH时只传一个根路径CMake 会把 include 和 lib 都搜到。Debug 和 Release 分开还有一个隐藏好处PDB 文件不会互相覆盖。调试时断点能不能命中取决于 PDB 是不是和 DLL 同版本混装的话你看到的永远是“当前不会命中断点”。2.3 第三方依赖版本配对zlib、libpng、curl、GDAL 与 GEOS 怎么选OSG 3.6.5 对第三方库是“可选但有更好”osgEarth 3.4.0 则是“没 GDAL 基本跑不起来”。先看一张我常用来对表的清单依赖库OSG 3.6.5osgEarth 3.4.0可用版本区间zlib需要需要1.2.11 以上libpng需要不需要1.6.xlibjpeg需要不需要8/9 均可libtiff可选用于影像访问4.xcurl可选网络瓦片时必需7.80 以上GDAL可选强烈建议2.4.x 到 3.6.xGEOS不需要矢量分析时需要3.8 以上SQLite3不需要缓存时必须3.x 任意这套版本区间不是死规矩实际用下来关键点是“ABI 别太激进”。比如 GDAL 3.7 之后头文件布局变化不小osgEarth 3.4.0 的 CMake 查找还能过但链接时偶尔会冒出几个 unresolved external symbol。想少翻车GDAL 选 2.4.x 或 3.5 之前的版本GEOS 选 3.9 左右的稳定版即可。依赖安装方式我推荐手动下载预编译包展开进osg-3rdparty而不是用 vcpkg 一把梭。vcpkg 的问题在于它默认把库安装到自己的目录Debug 和 Release 的运行时库也可能和你 OSG 编译选项不一致后面链接时_ITERATOR_DEBUG_LEVEL不匹配是常客。手动展开虽然累一点但每个库的 include、lib、bin 都一目了然出问题时你知道自己手里拿的是什么。2.4 CMake 生成器与架构参数为什么选 Visual Studio 17 2022 x64OSG 和 osgEarth 都是 CMake 工程Windows 下最省事的生成器是Visual Studio 17 2022。注意架构必须显式指定-A x64否则 CMake 默认生成 Win32 工程编译出来的库是 32 位和 osgEarth 混用时会在链接期爆一堆LNK1112: module machine type x86 conflicts with target machine type x64。另一个值得理解的参数是CMAKE_CONFIGURATION_TYPES。VS 生成器是单次配置、多配置编译不像 Makefile 那种先cmake -DCMAKE_BUILD_TYPEDebug再重配。把它设成Debug;Release生成的.sln里两个配置都有MSBuild 时用--config Debug切换即可。下面是 OSG 编译时一个可用的 CMake 配置命令后面解释每个参数为什么这样填cmake -S . -B build-vs2022 -G Visual Studio 17 2022 -A x64 ^ -DCMAKE_CONFIGURATION_TYPESDebug;Release ^ -DCMAKE_INSTALL_PREFIXD:/3rdparty/osg-3.6.5 ^ -DCMAKE_PREFIX_PATHD:/3rdparty/osg-3rdparty ^ -DBUILD_OSG_EXAMPLESOFF ^ -DBUILD_OSG_APPLICATIONSON ^ -DOSG_USE_GRAPHICS_SWITCHON ^ -DOSG_WINDOWING_SYSTEMWin32-DCMAKE_INSTALL_PREFIX是安装根cmake --install时会用到。-DCMAKE_PREFIX_PATH指向第三方依赖根目录CMake 内部用find_package找 zlib、libpng 和 GDAL 时都会优先看这里。BUILD_OSG_EXAMPLESOFF是把示例关掉OSG 的示例工程又多又杂编译时容易拖慢整体时间非学习目的可以不开BUILD_OSG_APPLICATIONSON则保留 osgviewer 等命令行工具后面做验证很有用。OSG_WINDOWING_SYSTEMWin32是让 OSG 走 Win32 窗口系统如果你后续要把 OSG 嵌入 Qt需要改成 Win32 再加 Qt 支持这个属于另一个话题先按下不表。3. 编译 OSG 3.6.5CMake 配置到 MSBuild 批量构建3.1 用命令行生成 VS2022 工程一条命令把 3.6.5 配置好在 OSG 3.6.5 源码根目录执行上一章的 cmake 命令重点是-G Visual Studio 17 2022 -A x64。生成成功后build-vs2022 下会出现 OpenSceneGraph.sln。命令行不是唯一选项用 CMake GUI 填同样的变量效果相同差别在于 GUI 里很容易漏掉CMAKE_PREFIX_PATH结果 zlib、libpng 全部找不到只能一路 Next 跳过最后编出来的 OSG 连 PNG 都读不了。我习惯用命令行因为变量写进批处理后可以复用。CMake 配置时会输出一串第三方库的检出信息比如-- Found GDAL: D:/3rdparty/osg-3rdparty/lib/gdal_i.lib -- Found ZLIB: D:/3rdparty/osg-3rdparty/lib/zlib.lib看到Found是正常的。如果某个库显示NOTFOUND但你也用不到比如 libcurl可以不管。GDAL 如果找不到osgEarth 后面一定出问题所以 OSG 阶段就要盯紧 GDAL 的状态。生成完毕后不要急着整个 sln 都编译。OSG 3.6.5 的解决方案工程数量在 60 个上下其中还包括一堆示例项目全编译用时很长。我们已经在 CMake 阶段关闭了示例剩下的就是插件和核心库可以放心用 MSBuild。3.2 MSBuild 批量编译Debug 和 Release 各来一遍在 Developer PowerShell 里进入 build-vs2022 目录执行msbuild OpenSceneGraph.sln /m:8 /p:ConfigurationDebug /p:Platformx64 msbuild OpenSceneGraph.sln /m:8 /p:ConfigurationRelease /p:Platformx64/m:8是并行编译进程数。如果你的机器 16GB 内存/m:4更稳32GB 以上再上/m:8不然编译器进程太多内存吃满后反而是玄学谁先崩谁。/p:ConfigurationDebug和/p:ConfigurationRelease分别对应 CMake 里配置的两个类型。首次编译时间主要耗在插件上。OSG 3.6.5 的插件项目规模不小Debug 模式比 Release 更慢通常单配置在 20 到 40 分钟不等。编完后检查 build 下的 bin 目录应该能看到osgversion.exe和osgPlugins-3.6.5文件夹。验证一下版本.\bin\Debug\osgversion.exe --version如果输出了类似3.6.5的版本号说明核心库没问题。再检查osgPlugins-3.6.5目录里 DLL 的数量Debug 模式下文件名带dRelease 不带。数量对不上说明有插件编译失败看编译日志里 error 的项目名一般是缺第三方库比如osgdb_png需要 libpng。3.3 安装成两套Debug 和 Release 分开落地编译成功不等于安装成功。OSG 的 CMake 提供了 install 规则但不会自动把第三方依赖的 DLL 拷进 bin。先看安装命令cmake --install build-vs2022 --config Debug --prefix D:/3rdparty/osg-3.6.5-debug cmake --install build-vs2022 --config Release --prefix D:/3rdparty/osg-3.6.5-release--config指定从哪个配置安装--prefix覆盖 CMake 配置时的安装前缀。安装完成后Debug 目录下 lib 里是osgCored.lib这类带 d 的库Release 目录下是正常命名的库。这样 osgEarth 配置即可用OSG_DIR分别指向这两套目录。这里有个容易忽略的步骤把D:/3rdparty/osg-3rdparty/bin下的 zlib.dll、libpng DLL、gdal DLL 等全部拷到 OSG 的 bin/Debug 和 bin/Release 里。OSG 运行时按相对路径或者 PATH 找第三方 DLL你不拷后面跑 osgviewer 就报“找不到 zlib.dll”看起来像是 OSG 编坏了其实只是依赖缺失。把它当成安装的一部分每次编译第三方依赖后都同步拷一遍能少踩一半坑。3.4 验证核心库与插件完整性先做一个最直接的验证直接跑 osgviewer 加载一个模型文件。如果手头有.osgt或.obj文件执行.\bin\Debug\osgviewer.exe D:/data/model.obj能弹出一个窗口说明 OSG 渲染、插件、Win32 窗口系统都通了。没有模型文件就加载 osg 自带的一个地模样例.\bin\Debug\osgviewer.exe --image D:/3rdparty/osg-3rdparty/...或者通过osgconv.exe转格式验证插件加载。无论如何osgversion 只是版本自检真正的验证要落到“读一个文件并渲染”。这一步至少证明 OSG 的osgDB插件注册表工作正常否则后面编译 osgEarth 时它自己的osgdb_osgearth_*插件也会在运行时加载失败。4. 编译 osgEarth 3.4.0CMake 配置里最容易被忽略的依赖路径4.1 osgEarth 3.4.0 与 OSG 3.6.5 的配对关系osgEarth 对 OSG 的版本绑定比较敏感。3.4.0 发布时配套的就是 OSG 3.6.x 系列其中 3.6.5 是社区里用得最多的一个组合。你如果手里是 OSG 3.6.3 或 3.6.6也能编过但尽量别用 3.6.7 之后的版本去配 osgEarth 3.4.0。原因不是编译期报错而是运行时插件加载时符号版本不一致可能崩在osgEarth::MapNode的某个虚函数调用上。这类问题没有任何提示排查起来最费时间。osgEarth 3.4.0 的 CMake 配置对 OSG 的查找是通过OSG_DIR定位的这个变量要指向 OSG 的安装根目录也就是包含include/osg和lib/osgCore.lib的目录。如果你是 Debug 和 Release 分开安装的配置 osgEarth 时也要分开给 OSG_DIR编译 Debug 的 osgEarth 指到osg-3.6.5-debugRelease 指到osg-3.6.5-release。混着指虽然也可能链接通过但运行时加载 DLL 时会串调试时你会看到 Debug 程序里加载了一个 Release 的 osgEarthd.dll 副本。4.2 osgEarth 的依赖结构GDAL、GEOS、SQLite3 与 curl 怎么配osgEarth 3.4.0 的依赖里GDAL 是核心中的核心影像数据基本靠它读GEOS 是做矢量叠加、几何关系分析时的底层库SQLite3 用于本地缓存curl 用于访问在线瓦片服务。这四样在 CMake 中的查找变量不同常见做法是分别传GDAL_DIR、GEOS_DIR、SQLITE3_ROOT、CURL_DIR再统一配合CMAKE_PREFIX_PATH兜底。如果你在 OSG 编译阶段已经让 CMake 找到了 GDAL说明 GDAL 的目录结构没问题osgEarth 复用同一套即可。有一个很容易踩的细节GDAL 的 Windows 预编译包通常只有一个gdal_i.lib不会区分 Debug 和 Release。这意味着你编译 osgEarth Debug 版时链路的是同一个 GDAL 库文件。只要这个 GDAL 本身是用/MD编译的而你的 OSG 和 osgEarth 也用/MD就不会冲突但如果你的 OSG 用了/MTGDAL 默认/MD链接器直接报 runtime library 不匹配。这就是为什么要统一运行时库后面避坑章节再展开。4.3 CMake 配置 osgEarthDebug 与 Release 分开配置一次到位在 osgEarth 3.4.0 源码根目录执行cmake -S . -B build-debug -G Visual Studio 17 2022 -A x64 ^ -DCMAKE_CONFIGURATION_TYPESDebug ^ -DCMAKE_INSTALL_PREFIXD:/3rdparty/osgearth-3.4.0-debug ^ -DOSG_DIRD:/3rdparty/osg-3.6.5-debug ^ -DGDAL_DIRD:/3rdparty/gdal ^ -DGEOS_DIRD:/3rdparty/geos ^ -DCMAKE_PREFIX_PATHD:/3rdparty/osg-3rdpartyDebug 和 Release 分成两个 build 目录而不是在一个.sln里同时开双配置。原因在于OSG_DIR指向哪一套 OSG链接时就认哪一套库用一个 sln 双配置VS 在切换 Configuration 时会切到同一组 CMake 变量没法自动切 OSG_DIR。分开配置虽然多跑一次 cmake但每个配置引用的依赖路径完全独立运行时不打架。配置完成后编译和安装msbuild build-debug/osgEarth.sln /m:8 /p:ConfigurationDebug /p:Platformx64 msbuild build-debug/osgEarth.sln /m:8 /p:ConfigurationRelease /p:Platformx64 cmake --install build-debug --config Debug --prefix D:/3rdparty/osgearth-3.4.0-debug cmake --install build-debug --config Release --prefix D:/3rdparty/osgearth-3.4.0-release如果你也选了 Debug/Release 双配置的方式注意 osgEarth 的 Release 配置要重新用指向 OSG Release 的 OSG_DIR 配置一遍否则 Release 链接的是 Debug 的 OSG。稳妥起见严格按下述步骤先build-debug指 Debug OSG生成后只编 Debug然后建build-release指 Release OSG只编 Release。4.4 把 osgEarth 插件放进 OSG 的插件目录osgEarth 编译完成的 DLL 里真正被 OSG 运行时要加载的是osgdb_osgearth_*.dll插件比如 image、tms、feature 等驱动。这些插件如果只留在 osgEarth 自己的bin目录下OSG 不会自动去那里找你跑 osgearth_simple 时会报Failed to locate plugin osgearth_image常见做法是在 osgEarth 安装完成后把bin下所有osgdb_osgearth_*DLL 和osgEarth*.dll核心 DLL 复制进 OSG 对应配置的osgPlugins-3.6.5目录。Debug 和 Release 分开复制避免同名 DLL 互相覆盖。除了插件还要把 osgEarth 的库 DLL 复制到 OSG 的 bin/Debug 或 bin/Release 下或者加入 PATH。这一步做完OSG 的插件机制才能正确发现 osgEarth 的驱动。5. VS2022 编译避坑记录五个反复出现的雷区5.1 C4996c 64位 fopen 报安全错误老代码被 MSVC 卡住现象编译 OSG 3.6.5 时错误列表大量出现C4996 fopen: This function or variable may be unsafe。看起来 Delta 很大实际上 3.x 源码里用了不少旧 C 库函数而 VS2022 默认开了 SDL 或对 CRT 函数做了弃用标记。原因MSVC 把 fopen、strcpy 这类函数标记为 deprecated建议用fopen_s等带_s后缀的替代。老代码跨平台不会为了 Windows 专门改掉所有调用。解决在 CMake 配置时加上编译宏/D _CRT_SECURE_NO_WARNINGS绕过安全性检查提示不改变函数行为。在 CMake GUI 中把它追加到CMAKE_CXX_FLAGS或者命令行这样传-DCMAKE_CXX_FLAGS/D _CRT_SECURE_NO_WARNINGS也可以加/wd4996只屏蔽该编号警告效果类似。注意别把/WX警告当错误开着否则加了 /wd4996 也可能被其他警告拦下。5.2 LNK2038 运行时库不匹配Debug 和 Release 库混用现象链接 osgEarth 时报LNK2038 mismatch detected for _ITERATOR_DEBUG_LEVEL: value 2 doesnt match value 0。原因_ITERATOR_DEBUG_LEVEL为 2 表示使用 Debug 运行时库/MDd为 0 表示 Release/MD。别的手写库或第三方库没有统一运行时Debug 工程里链了一个 Release 编译的静态库MSVC 直接拒绝链接。解决统一所有库的运行时模式。CMake 3.15 起可以在配置时设CMAKE_MSVC_RUNTIME_LIBRARYMultiThreadedDLL或者直接在 CXX_FLAGS 里加/MDDebug 用/MDd。最省心的办法是从一开始就把 OSG、osgEarth、GDAL、GEOS 全部按“多线程 DLL”配置不要出现某个库用/MT而主程序用/MD。你手头如果有别的团队编的第三方库先确认它的运行库模式再决定是否纳入。5.3 CMake 找不到 GDAL 或找到的库不能用现象配置 osgEarth 时CMake 提示Could NOT find GDAL (missing: GDAL_INCLUDE_DIR GDAL_LIBRARY)或者好不容易找到了链接时爆一堆unresolved external symbol GDALAllRegister。原因第一种情况是GDAL_DIR指错了地方没有指到含include/gdal_priv.h和lib/gdal_i.lib的同级目录。第二种情况是 include 和 lib 来自不同版本最常见的是 include 是 GDAL 3.xlib 却是 2.x 的接口函数对不上。解决GDAL_DIR指到 GDAL 根目录并且该目录下同时存在 include 和 lib。找一个能通过的简单验证cmake --find-package -DNAMEGDAL -DCOMPILER_IDMSVC -DLANGUAGECXX -DMODEEXIST如果能找到再检查里面gdal_version.h的版本号和 lib 文件名是否一致。如果 lib 只有gdal_i.lib而 include 头文件版本远新于 lib建议统一换成 2.4.x 这个经典版本避免后续链接问题。5.4 osgPlugins 插件加载失败Could not locate plugin现象自己写的程序编译通过运行时报Could not locate plugin osgearth_image或osgdb_osgearth_gdal。程序在开发机上好好的拷贝到别的机器就找不到。原因Windows 下 OSG 在启动时按osgPlugins-3.6.5目录查找插件 DLL。osgEarth 的插件分散在它自己的安装目录里没进 OSG 的插件目录换机器后 PATH 也没带过去。解决把 osgEarth 安装目录 bin 下所有osgdb_osgearth_*DLL 复制到 OSG 的osgPlugins-3.6.5目录并把 osgEarth 的 DLL 所在目录加进系统 PATH或者把它们也复制到 OSG 的 bin 下。Debug 和 Release 的插件目录分开复制两个版本别共用同一份文件。5.5 CMAKE_INSTALL_PREFIX 重复使用旧版本头文件污染新编译现象同一台机器上连续编译过 OSG 3.6.4 和 3.6.5或者把 osgEarth 老版本装到了同一个前缀过段时间编新工程时出现诡异的版本断言现象是osg/Version头文件里的版本号不是你要的或者符号签名对不上。原因CMake 安装命令不会清理旧文件同一个CMAKE_INSTALL_PREFIX下新老版本的头文件、库和 PDB 混在一起。find_package搜索时先读到旧的头文件于是链接期检到的接口版本错位。解决严格执行一版本一目录安装前缀必须带上版本号和配置类型比如osg-3.6.5-debug。编译项目之前先检查该目录里是否只存在目标版本的头文件。如果你已经发生过污染删掉整个前缀目录重新 install不要抱侥幸心理只清部分文件。6. 验证与自动化三件事帮你巩固这套自编译成果6.1 用 osgearth_simple 跑通一个带 GDAL 影像的 earth 文件编译完 osgEarth最怕的是“编过了但不知道行不行”。osgEarth 3.4.0 自带一个osgearth_simple示例工具可以加载.earth文件并展示地球。先准备一个最小 earth 文件map options profilespherical-mercator/profile /options image drivergdal urlD:/data/satellite.tif/url /image /map然后执行osgearth_simple.exe D:/data/simple.earth弹出一个显示卫星影像的地球窗口说明 OSG、osgEarth、GDAL 三分支在运行时已经打通。如果没有窗口先确认osgearth_simple.exe和 osgEarth 的 DLL 在同一个目录插件是否复制进了osgPlugins-3.6.5这能排除一半的运行时问题。6.2 在 Visual Studio 里确认 Debug 调试链路完整X64 Debug 调试的关键在于链接库里带的 PDB 与运行加载的 DLL 是否完全匹配。自己编译的 Debug 版链接时osgEarthd.lib和osgdb_osgearth_imaged.dll都要使用同一份源码生成的产物。进入 VS 调试后在“调试 - 窗口 - 模块”里看加载的模块应该显示“已加载符号”而不是“无法找到或打开 PDB 文件”。如果断点打不进 osgEarth 源码优先检查链接的是不是 Debug 库项目属性 - 链接器 - 输入 - 附加依赖项Debug 配置应包含osgEarthd.libRelease 配置应包含osgEarth.lib。混用的话调试链路一定断。6.3 保留一份双配置构建脚本下次一条命令跑完自己编译一次已经很费时间不值得第二次重新敲一遍 CMake 参数。更简单的做法是在D:/3rdparty下放一个build-all.bat里面依次是 OSG 和 osgEarth 的配置、编译、安装步骤。脚本核心部分如下echo off set SRC_OSGD:/dev/OpenSceneGraph-3.6.5 set SRC_OED:/dev/osgEarth-3.4.0 set 3RDPARTYD:/3rdparty cmake -S %SRC_OSG% -B %SRC_OSG%/build-debug -G Visual Studio 17 2022 -A x64 ^ -DCMAKE_CONFIGURATION_TYPESDebug ^ -DCMAKE_PREFIX_PATH%3RDPARTY%/osg-3rdparty msbuild %SRC_OSG%/build-debug/OpenSceneGraph.sln /m:8 /p:ConfigurationDebug cmake --install %SRC_OSG%/build-debug --config Debug --prefix %3RDPARTY%/osg-3.6.5-debug把%SRC_OSG%改成你自己解压的源码路径按同样的模式复制一份给 osgEarth再把 Release 配置也加上。以后新换机器只需安装 VS2022、设置依赖目录最后执行一次批处理即可得到完整产物。我自己的习惯是每次编译完顺手把生成时间、用了哪几个第三方库的小版本号写进脚本注释里。下次换个 GDAL 或者改插件时翻一眼就能判断哪些库需要重编不用再从头查起。如果你也打算长期维护 osgEarth 工程这套“自编译 双配置 固定依赖目录”的工作流值得一次性搭好省下的时间远多于第一次折腾的成本。希望这篇文章能帮到你少走我当年走过的弯路。本文还有配套的精品资源点击获取