简介基于最新VTK 9.3.1版本、面向VS2019与Qt5.15.2环境的编译成果包专供需要开发三维可视化与图形处理应用的开发者可避免从源码自行编译的复杂过程。压缩包内含x64架构下的Debug与Release两套编译结果兼顾调试与发布场景。全部文件共2000个以1944个C头文件为核心另附56个hpp辅助头文件适合直接集成到现有C工程中。包体大小120.06MB已有437人学习或下载。利用这套SDK开发者能快速接入VTK丰富类库同时结合原始博客的编译说明可掌握环境配置与构建要点便于后续定制扩展。整体而言这份资源大幅降低了VTK入门门槛让开发者把精力集中在渲染算法与业务逻辑上。1. 为什么 VTK 9.3.1 还得从源码自编译 SDK老工具链的尴尬位置做医学影像、点云可视化和数值仿真后处理的团队很多至今还锁在 VS2019 Qt5.15.2 这套工具链上。VTK 9.3.1 是目前 9.3 系列里比较新的修订版但官方没有直接分发一套“适配 VS2019、带 Qt 模块、Windows x64 双配置”的现成 SDK。网上的预编译包要么版本停留在 8.x/9.0要么压根没有编进去 Qt 的那几个模块拿回来一跑就“缺 VTK::GUISupportQt”。自己拿源码编一套 SDK几乎成了继续往下做应用开发的必经之路。这篇笔记围绕 VTK9.3.1 VS2019 Qt5.15.2 这个组合把从 CMake 配置、VS2019 里编译、产出 debugrelease 两套 x64 产物到接进 Qt 程序验证可用这件事讲完适合已经装好环境、想一次把头文件库文件备齐的 C 桌面开发同学。2. 编译前先想明白VTK 9.3.1 搭配 VS2019 的选型与 CMake 开关2.1 三条硬性约束编译器、Qt 套件、x64 架构先别急着点 configure这套工具链有三条底线必须压住。第一编译器必须和 Qt 套件对齐。Qt 5.15.2 官方提供了 msvc2019_64 前缀这套库是拿 VS2019 的 v142 工具集编出来的。VTK 9.3.1 的 Windows 版本推荐用同一套 MSVC否则后面链接阶段会出现“编译器版本不匹配”的报错或运行时崩溃。如果你在 Qt 安装时只选了 msvc2017_64VS2019 也能勉强用但 CRT 和 STL 实现细节上的差异会给你埋雷我建议直接重新加装 msvc2019_64 组件。第二VTK 的 Qt 模块不是默认编的。VTK 9 引入了一套模块组开关Qt 相关模块默认是 WANT看情况而不是 YES如果你不显式把VTK_GROUP_ENABLE_Qt打开编出来的 VTK 里根本没有 QVTKOpenGLNativeWidget 这套东西等你在代码里 include 时才发现就晚了。第三x64 不只是“选一下平台”那么简单。VTK 9.3.1 本身可以在 Win32 下编但你后续搭配 Qt 的 msvc2019_64 库整个进程必须统一成 x64。CMake 生成 VS2019 工程时除了-A x64这个参数还要保证你的 Qt 前缀路径指向 msvc2019_64而不是指向某个 x86 的 mingw 或 msvc 目录。混架构的典型症状是链接时报一堆无法解析的外部符号因为 32 位库的导入库格式和 64 位目标对不上。2.2 CMake 配置清单哪些开关必开哪些可以关掉VTK 9.3.1 的 CMake 选项非常多但真正影响我们这个场景的其实就十几个。先给一份可以直接抄的配置清单参数建议值理由VTK_GROUP_ENABLE_QtYES必开否则不生成 Qt 相关头文件VTK_QT_VERSION5明确走 Qt5避免默认探测到 Qt6BUILD_SHARED_LIBSON动态库方便部署也有利于多模块链接VTK_BUILD_TESTINGOFF测试代码占大量编译时间SDK 不需要VTK_BUILD_EXAMPLESOFF关闭示例缩短构建时间VTK_GROUP_ENABLE_MPINO串行应用的 SDK 不需要 MPI 依赖CMAKE_CONFIGURATION_TYPESDebug;Release让 VS2019 一次生成两种配置CMAKE_PREFIX_PATHQt 安装路径让 find_package 找到 Qt5CMAKE_INSTALL_PREFIX自定义 SDK 目录决定最终头文件和库的落点这里重点解释BUILD_SHARED_LIBSON这条。很多人为了让最终 exe 干净倾向选OFF编静态库。但 VTK 9 的静态编译有几个麻烦一是模块多静态库全量链接非常慢二是 VTK 的 object factory 机制在静态库下更容易踩 LNK2019三是 Qt5.15.2 的官方库本身就是动态的你静态编 VTK 的 Qt 模块时还要额外处理 Qt 的 plugin 路径问题。实际项目里我用下来动态库反而是最稳的。部署时把bin目录下这些 DLL 一并带上就行。VTK_GROUP_ENABLE_MPINO这条容易被忽略。默认情况下 VTK 的 MPI 组是 WANT如果你的机器上装了 MS-MPICMake 真会把它找出来编进去纯粹白增加编译时间。显式关掉后整个构建会清爽不少。2.3 Debug 和 Release 同时编的架构选择一次 VS 工程两套产物VTK 9.3.1 的 CMake 生成器如果选 “Visual Studio 16 2019”天然是一个多配置生成器。也就是说你只需要 configure 一次VS2019 里会自动出现 Debug 和 Release 两个配置不需要跑两遍 CMake。这里有个关键点CMAKE_CONFIGURATION_TYPES如果不显式给CMake 默认是空VS 工程里可能只剩下 Debug。你必须在 configure 命令行里加上-DCMAKE_CONFIGURATION_TYPESDebug;Release这两个配置共享同一套生成好的解决方案文件但各自生成的 DLL 文件命名规则不同。VTK 在 Debug 配置下会给所有动态库加上_d后缀比如vtkCommonCore-9.3.dll对应 Debug 版本是vtkCommonCore-9.3d.dll。Release 配置则没有后缀。这个命名规则后面避坑章节还会用到先记个印象。另外建议把 Release 和 Debug 的代码生成选项保持默认的/MD和/MDd不要动成/MT。VTK 官方推荐的 Windows 构建风格是动态 CRT你如果图省事改成静态 CRT后面 Qt 库、第三方库直接教做人。3. 用 CMake VS2019 把 VTK 9.3.1 编译成 SDK完整命令与目录产物3.1 最小 CMAKE 配置命令假设源码解压在D:\thirdparty\VTK-9.3.1Qt 装在C:\Qt\Qt5.15.2\5.15.2\msvc2019_64在 PowerShell 里执行下面的命令cmake -S D:\thirdparty\VTK-9.3.1 -B D:\build\VTK-9.3.1-build -G Visual Studio 16 2019 -A x64 -DCMAKE_PREFIX_PATHC:\Qt\Qt5.15.2\5.15.2\msvc2019_64 -DCMAKE_INSTALL_PREFIXD:\SDK\VTK-9.3.1-msvc2019-x64 -DVTK_GROUP_ENABLE_QtYES -DVTK_QT_VERSION5 -DBUILD_SHARED_LIBSON -DVTK_BUILD_TESTINGOFF -DVTK_BUILD_EXAMPLESOFF -DVTK_GROUP_ENABLE_MPINO -DCMAKE_CONFIGURATION_TYPESDebug;Release-S指定源码根目录-B指定构建目录。用-G指定生成器是 Visual Studio 16 2019也就是 VS2019-A x64指定 64 位架构。值得说的是-DCMAKE_PREFIX_PATHCMake 的find_package会用这个路径去找 Qt5 的配置文件如果你的 Qt 路径带空格记得用双引号括起来。VTK_QT_VERSION5这条在只装了 Qt5 的机器上可以省略但如果你机器上同时装了 Qt6CMake 可能会自动探测到 Qt6 然后编一套不适合的 Qt 模块。显式指定最稳。执行后看到 CMake 输出里出现Qt5 found并且 Pass through 了相关模块说明 Qt 被正确识别。如果输出里只看到Qt5 NOT_FOUND大概率是CMAKE_PREFIX_PATH指错了层应该指向到msvc2019_64而不是指到 Qt 安装总目录。3.2 VS2019 里构建的顺序与配置切换configure 完成后D:\build\VTK-9.3.1-build下会出现VTK.sln。用 VS2019 打开它第一件事不是点生成而是把解决方案配置从 Debug 切到 Release再在解决方案资源管理器里确认是 x64 平台。构建目标顺序有个讲究先编ALL_BUILD再编INSTALL。ALL_BUILD会编译整个 VTK 项目组模块多耗时很长。建议在 VS2019 里选择“生成解决方案”而不是右键单独编译某一个项目。模块之间有依赖关系单独编译某个目标会缺一堆头文件。如果命令行操作更顺手可以在构建目录下执行cmake --build D:\build\VTK-9.3.1-build --config Debug --target ALL_BUILD cmake --build D:\build\VTK-9.3.1-build --config Release --target ALL_BUILD--config参数指定配置因为 VS 是多配置工程命令行必须显式给不然 CMake 默认会编 Debug。建议先编 Release再编 Debug因为 Release 的优化项能提前暴露一部分编译期问题而且如果机器内存不够两个配置同时并行反而容易 OOM。这一步的产物会落在D:\build\VTK-9.3.1-build\bin\Debug和bin\Release下一堆 DLL 和几个 exe。注意别直接把这两个目录当 SDK 用里面还夹着测试程序和中间文件后面得走 INSTALL。3.3 执行 INSTALL把纯净产物收敛成 SDK 目录ALL_BUILD完成后继续执行 INSTALL 目标。这一步会把头文件、库文件、CMake 配置、DLL 按标准结构复制到前面设置的CMAKE_INSTALL_PREFIX目录。cmake --build D:\build\VTK-9.3.1-build --config Debug --target INSTALL cmake --build D:\build\VTK-9.3.1-build --config Release --target INSTALL两个配置都执行 INSTALL 后D:\SDK\VTK-9.3.1-msvc2019-x64目录结构大致长这样D:\SDK\VTK-9.3.1-msvc2019-x64\ bin\ Debug\*.dll Release\*.dll lib\ Debug\*.lib Release\*.lib include\vtk-9.3\ cmake\vtk-9.3\ share\doc\第一次编 VTK 的人容易在这里犯一个错误编完 ALL_BUILD 就把构建目录里的include和lib拷出去用以为这就成了 SDK。实际上build\include里只有 CMake 探测生成的临时头文件缺很多随模块生成的源码头文件build\lib里也有 Debug 和 Release 的库混在一起没有区分。只有 INSTALL 出来的目录才是干净、可发布的 SDK。lib目录下 Debug 的导入库文件名带_d后缀比如vtkCommonCore-9.3d.libRelease 是vtkCommonCore-9.3.lib。应用工程链接时CMake 会根据当前配置自动选对应后缀不需要你手动指定。include\vtk-9.3下是全部公共头文件大约 40 多个目录对应各个模块。检查一下有没有QVTKOpenGLNativeWidget.h就能确认 Qt 模块真的编进去了。3.4 把安装目录变为可移植 SDK 的一个小习惯INSTALL 结束后建议把整个VTK-9.3.1-msvc2019-x64目录压成一个包随项目走。不要把构建目录build也打成包那里面是构建中间产物换一台机器路径变了就失效。在 SDK 顶层目录手动补充一个README.txt写清楚三个事编译器版本是 VS2019 v142、Qt 版本是 5.15.2 msvc2019_64、当前包含 Debug 和 Release 两种配置。这个习惯能省掉很多“过两月回来看不知道这套库怎么来的”的麻烦。后面接 Qt 程序时你的find_package会用到这个安装目录里的 cmake 配置文件路径别乱移动。4. 把自编译 SDK 接进 Qt 程序最小 Demo 的 CMake 与代码4.1 消费 SDK 的 CMakeLists.txt 写法SDK 编完不是终点能编译出一个带 VTK 渲染窗口的 Qt 程序才证明这套产物真的可用。写一个最小 demo目录结构如下D:\demo\ CMakeLists.txt main.cppCMakeLists.txt内容cmake_minimum_required(VERSION 3.16) project(demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 告诉 CMake 去哪里找 Qt5 和 VTK 的配置文件 list(APPEND CMAKE_PREFIX_PATH C:/Qt/Qt5.15.2/5.15.2/msvc2019_64 D:/SDK/VTK-9.3.1-msvc2019-x64 ) find_package(Qt5 5.15 REQUIRED COMPONENTS Widgets) find_package(VTK 9.3 REQUIRED COMPONENTS GUISupportQt RenderingContextOpenGL2 RenderingQt ) add_executable(demo main.cpp) target_link_libraries(demo PRIVATE Qt5::Widgets ${VTK_LIBRARIES} ) # VTK 9 的 object factory 需要这行自动初始化不写会 LNK2019 vtk_module_autoinit( TARGETS demo MODULES ${VTK_LIBRARIES} )VTK_LIBRARIES是所有 REQUIRED COMPONENTS 被满足后自动收集的一组导入目标。vtk_module_autoinit是 VTK 9 新增的关键函数作用是为目标链接的所有 VTK 模块生成初始化代码。很多从 VTK 8 迁过来的项目会漏这一行结果链接时报vtkRenderingOpenGL2_AUTOINIT相关错误。CMake 配置时如果提示find_package找不到 VTK回头看 3.3 里的 INSTALL 是否执行过以及CMAKE_PREFIX_PATH是否指向了 SDK 根目录而不是lib或include。4.2 main.cpp 里 VTK 渲染与 Qt 事件循环的配合main.cpp里最关键的是渲染窗口的类型选择。VTK 9 里不要再直接 newvtkRenderWindow塞到 Qt 控件里要用vtkGenericOpenGLRenderWindow#include QApplication #include QSurfaceFormat #include QVTKOpenGLNativeWidget.h #include vtkGenericOpenGLRenderWindow.h #include vtkRenderer.h #include vtkNew.h #include vtkConeSource.h #include vtkPolyDataMapper.h #include vtkActor.h #include vtkProperty.h int main(int argc, char* argv[]) { // 让 Qt 和 VTK 共享同一个 OpenGL 上下文 qputenv(QT_OPENGL, desktop); QApplication::setAttribute(Qt::AA_ShareOpenGLContexts); QApplication app(argc, argv); // 设置默认的 surface format保证兼容 VTK 渲染管线 QSurfaceFormat::setDefaultFormat(QVTKOpenGLNativeWidget::defaultFormat()); vtkNewvtkRenderer renderer; vtkNewvtkGenericOpenGLRenderWindow renderWindow; renderWindow-AddRenderer(renderer); QVTKOpenGLNativeWidget widget; widget.setRenderWindow(renderWindow); widget.resize(1024, 768); // 建一个圆锥体放在场景里用于验证管线是通的 vtkNewvtkConeSource cone; vtkNewvtkPolyDataMapper mapper; mapper-SetInputConnection(cone-GetOutputPort()); vtkNewvtkActor actor; actor-SetMapper(mapper); actor-GetProperty()-SetColor(0.2, 0.6, 0.9); renderer-AddActor(actor); renderer-SetBackground(0.95, 0.95, 0.95); widget.show(); renderer-ResetCamera(); return app.exec(); }说明几个关键点。QApplication::setAttribute(Qt::AA_ShareOpenGLContexts)必须放在QApplication构造之前这是 Qt5 与 VTK 共用 OpenGL 上下文的前提。QSurfaceFormat::setDefaultFormat用defaultFormat()初始化保证 OpenGL 版本、颜色缓冲等设置满足 VTK 要求。硬编码乱设一个QSurfaceFormat::setDepthBufferSize之类的写法不推荐直接沿用默认就行。widget.setRenderWindow(renderWindow)这一步替换掉了 VTK 8 时代常用的vtkRenderWindowInteractor初始化流程。之后对renderer的所有操作仍然按 VTK 习惯来不需要手动Render()Qt 的绘制事件会驱动重绘这在窗口大小改变、遮挡恢复时尤其省心。4.3 运行路径上需要带的 DLL以及怎么执行 demo生成的 exe 双击运行前确保以下三类 DLL 在PATH或 exe 同级目录下Qt 的Qt5Widgets.dll、Qt5Gui.dll、Qt5Core.dll以及platforms\qwindows.dllVTK SDK 的bin\Release\*.dll注意区分 Debug 版带_d后缀MSVC 运行库一般由 vc_redist 提供最简单的验证方式是在构建目录里执行cmake --build D:\demo-build --config Release D:\demo-build\Release\demo.exe如果因为缺 DLL 弹窗报错别急着拷贝一堆先用 Qt 的部署工具把 Qt 相关依赖补齐。在 Qt 的 bin 目录下执行C:\Qt\Qt5.15.2\5.15.2\msvc2019_64\bin\windeployqt.exe D:\demo-build\Release\demo.exe这个命令会自动分析 exe 依赖的 Qt 模块把需要的 DLL 和platforms目录复制到Release文件夹。之后再补上 VTK 的 DLL一般就只剩两种可能要么 VTK DLL 清单不全要么 OpenGL 驱动版本问题。VTK DLL 在VTK-9.3.1-msvc2019-x64\bin\Release下直接整目录复制进应用目录即可简单粗暴也可靠。5. 避坑VTK9.3.1 VS2019 Qt5.15.2 编译期与运行期高频问题5.1 Debug 库和 Release 库混用运行期随机崩溃现象Debug 版本的应用有时能启动但一操作界面就崩溃或者 Release 版跑得正常Debug 版在 VTK 内部报堆错误。原因find_package(VTK)本身会按当前配置选库但在你的应用工程里如果 CMake 缓存里残留旧的VTK_DIR路径或者你手动在链接器附加依赖项里写了vtkCommonCore-9.3.lib不带_d的 Release 库Debug 配置下就会链接到 Release 版 VTK。两个配置的堆管理器和 STL 实现不同内存布局对不上崩溃不可避免。解决不要在 VS 的“链接器→附加依赖项”里手动填任何 VTK 的.lib文件名让 CMake 的find_package和VTK_LIBRARIES自动管理。同时把应用工程的CMAKE_CONFIGURATION_TYPES也显式设为Debug;Release。写完后在main.cpp第一行加一句#include vtkVersion.h编译后到build\demo.dir\Debug下检查.tlog文件里的实际链接命令确认带不带_d后缀。这一步能一眼看出链接选没选对。5.2 配置时没认出 Qt编出来的库缺少 QVTK 模块现象CMake 配置输出里没有出现 Qt 相关的 Find 信息编完后include\vtk-9.3下找不到QVTKOpenGLNativeWidget.h你自己工程里一包含就 C1083。原因VTK_GROUP_ENABLE_QtYES没设或者CMAKE_PREFIX_PATH没指向msvc2019_64。VTK 9 的 Qt 模块组是独立控制的很多人在命令行里漏了VTK_QT_VERSION5而机器上又装了 Qt6CMake 就自作主张选了 Qt6但 Qt6 的库名规则和 Qt5 不完全一样编出来的模块对外还是以 Qt5 命名两头对不上。解决配置时三个参数一起给VTK_GROUP_ENABLE_QtYES、VTK_QT_VERSION5、CMAKE_PREFIX_PATH指向C:\Qt\Qt5.15.2\5.15.2\msvc2019_64。配置完成后在 CMake 的 GUI 里搜 Qt确认Qt5_DIR、Qt5Widgets_DIR这些变量都已经定位到 msvc2019_64 下的lib\cmake目录。不要手动改Qt5_DIR那是最后手段先检查前缀路径的层数对不对。5.3 LNK2019VTK 模块的 object factory 没有被初始化现象应用代码编译通过链接时报一大串unresolved external symbol vtkRenderingOpenGL2_AUTOINIT之类的错误或者运行时报no override found for vtkRenderWindow。原因VTK 9 把模块内部的 object factory 机制整理成了显式初始化的形式。在 MSVC 编译器下动态加载和静态链接的初始化规则都不如 GCC 那边宽松需要由 CMake 的vtk_module_autoinit生成一段初始化代码。老教程里教你#include vtkAutoInit.h然后宏定义VTK_AUTOINIT的做法不是不能用但很容易写错模块名。解决在 CMakeLists 里对目标调用vtk_module_autoinit这是官方推荐、也最不容易丢。前提是你通过find_package(VTK)拿到的${VTK_LIBRARIES}里有完整的模块列表。如果以target_link_libraries方式单写了VTK::GUISupportQt也一定要把对应模块名在 autoinit 里再声明一遍。我把这段代码固定写成一个vtk_setup.cmake文件放到公共 CMake 目录里每个新工程直接 include比每次手敲靠谱。5.4 运行时报“无法定位程序输入点”或“缺少 Qt5Widgets.dll”现象在开发机一切正常拷到另一台机器后双击 exe提示找不到Qt5Widgets.dll或者报某 DLL 的某个入口点找不到。原因缺少两种依赖Qt 运行库和 VTK DLL。前者常见于没执行windeployqt后者常见于只拷贝了 Qt 的 DLL 而漏了整个 VTKbin\Release目录。入口点报错更隐蔽往往是系统中存在旧版本 Qt DLL程序加载时优先挑中了它。解决发布前固定一套三条命令windeployqt.exe --release .\Release\demo.exe xcopy /E D:\SDK\VTK-9.3.1-msvc2019-x64\bin\Release .\Release\VTK\ set PATH%PATH%;.\Release\VTK;第三条是把 VTK DLL 所在目录临时加到PATH里仅用于本地验证。正式发布时要么把 VTK DLL 全部和 exe 放同目录要么用 Qt Installer Framework 做安装器时把该放的 DLL 按目录规则装进去。千万不要只拷贝几个“看起来用得到”的 VTK DLLVTK 模块间互相依赖漏一个就是入口点报错。5.5 QVTKOpenGLNativeWidget 黑屏或渲染区无内容现象程序能跑Qt 界面正常显示但 VTK 渲染区域黑屏或者只有背景色没有模型。原因这类问题大多是 OpenGL 上下文没有共享。VTK 渲染窗口通过setRenderWindow绑定到 Qt 控件但控件初始化 OpenGL 上下文时没有拿到正确的QSurfaceFormat。另一个常见原因是显卡驱动只支持 OpenGL 2.1 以下而 VTK 的 OpenGL2 后端要求 3.2 以上。解决先看驱动更新显卡驱动到支持 OpenGL 4.x 的版本。然后确认在创建QApplication之前已经调用QSurfaceFormat::setDefaultFormat(QVTKOpenGLNativeWidget::defaultFormat())并且AA_ShareOpenGLContexts是 true。在没有独立显卡的虚拟机上黑屏可以在main.cpp开头qputenv(QT_OPENGL, software)强制走软件渲染这个临时方案能帮你区分是 VTK 设置问题还是驱动问题但不建议长期这么干。6. 验证 SDK 输出的五个检查点以及把编译过程脚本化SDK 到底能不能交付靠“编完不报错”不算数得按检查点过一遍。第一include\vtk-9.3目录里有没有vtkVersion.h打开看VTK_VERSION_MAJOR是否是 9、MINOR是否是 3很多历史遗留的 SDK 版本号对不上代码里#if VTK_VERSION_NUMBER 9这种条件编译会直接跑偏。第二cmake\vtk-9.3目录下存在VTKConfig.cmake并且用 4.1 的find_package(VTK 9.3 REQUIRED COMPONENTS GUISupportQt)能正常通过。CMake 报版本不符说明你把不同版本 VTK 的安装目录混在一起了或者CMAKE_PREFIX_PATH里路径顺序不对旧的 VTK 被优先找到。第三lib\Debug和lib\Release下各有一整套导入库Debug 后缀_d.lib的数量与 Release 基本一致。可以写一条 PowerShell 快速比对$dbg Get-ChildItem .\lib\Debug\*.d.lib | ForEach-Object { $_.BaseName.Replace(.d,) } $rel Get-ChildItem .\lib\Release\*.lib | ForEach-Object { $_.BaseName } Compare-Object $dbg $rel没有输出差异说明双配置产物齐整。第四把 4.2 的 demo 分别用 Debug 和 Release 各编一次两个都能弹出窗口并显示蓝色圆锥体。这一步是最有说服力的也最容易发现 5.1 的混用问题。第五删除构建目录里 demo 的全部输出只保留 exe 和 SDK 里的 DLL重新运行一遍。这样做是为了排除“VS 调试环境下附带运行库”带来的侥幸。过完这五条这套 SDK 就可以在项目组里共用了。最后分享一个习惯我会把整个编译过程写成一个批处理脚本放在 SDK 目录的build.bat里参数化 CMake 和构建命令。每次拿到新机器先跑脚本再检查检查点前后不超过一小时。很多同事习惯在 VS 里手动点配置、点生成下次换台机器又重新来一遍中间漏掉一两步就成了玄学问题。把这套重复劳动脚本化反而能省掉日后最贵的排错成本。希望这篇笔记能帮你把 VTK 9.3.1、VS2019、Qt5.15.2 这套组合一次编通少走几趟弯路。本文还有配套的精品资源点击获取