简介面向Windows 10 64位系统上的Qt 5.9.6视觉项目开发这份编译好的OpenCV 3.2.0 MinGW版免去了自行配置CMake、检查依赖和交叉编译的繁琐工作可直接在Qt Creator中使用。包内含245个文件核心是145个hpp与57个h头文件提供cv命名空间下各类接口声明17个dll动态库与16个a导入库支撑运行时链接另有4个cmake配置辅助工程集成以及少量exe和txt实用说明整体仅10.61MB分发部署都很轻量。资源侧重MinGW/GCC工具链尤其适合不使用Visual Studio、习惯Qt搭配OpenCV的C开发者因已启用对Qt的链接支持CMake工程中集成路径清晰已有242人学习下载。包内可直接调用的库文件与说明文档便于围绕图像处理、特征检测等功能快速搭建桌面应用也方便对照实际环境校验链接配置。这些库文件已针对MinGW的常见调用方式整理齐全配合附带的cmake片段与txt说明几乎可以无缝嵌入现有Qt工程。1. 为什么这个组合值得花一整天OpenCV 3.2.0 MinGW Qt 5.9.6 的来龙去脉OpenCV 3.2.0 官方只发布 MSVC 编译的 Windows 安装包而你的 Qt 5.9.6 用的是 MinGW 套件两个编译器家族 ABI 不互通直接拿官方 lib 去链接报错的会是成片 undefined reference。网上多数答案会劝你换 MSVC 版 Qt那等于把整个工程推倒重来。这个标题要解决的事很具体在 Win10 上用 MinGW 把 OpenCV 3.2.0 完整编出来让它和 Qt 5.9.6 的 mingw53_32 套件链进同一个程序里。适合两种人依赖被锁死在 OpenCV 3.2.x 和 Qt 5.9 LTS 上的老项目维护者以及复现教材源码时发现官方包与 Qt 环境对不上号的初学者。两条路都逼你亲手把 CMake 全流程走一遍。整条链路拆开只有三步搭对 MinGW 环境、给 CMake 传对 Qt 开关、把产物按规矩放进 Qt 工程。下面拆开讲参数和坑都摆明面。2. 环境准备MinGW 与 Qt 5.9.6 的选型逻辑2.1 msvc 和 mingw 的 ABI 差异为什么不能混着用很多人搜 msvc 和 mingw 区别其实就想知道一件事能不能拿官方 OpenCV 的 lib 直接链进 MinGW 的 Qt 工程。答案是不能。MSVC 和 MinGW 虽然都是 Windows 下的 C/C 编译器但各自的 C 运行库msvcp140 对应 libstdc、名字修饰规则和导入库格式都不一样。MSVC 产出 .libMinGW 产出 .dll.a两者在链接器眼里根本不是同一种文件。如果强行混用最典型的结果是链接期报一整排 undefined reference to__imp_...。更麻烦的是有些库用 -fabi-version 之类的选项能勉强对上符号但底层 CRT 还是两套程序跑起来后在内存分配、异常处理上随时可能崩这类问题比编译失败更难排查。所以结论很干脆Qt 套件是 MinGWOpenCV 就必须是 MinGW 编出来的Qt 套件是 MSVCOpenCV 就用官方安装包没有第三条路。Qt 5.9.6 官方提供给 Windows 的预编译套件有两种标志msvc2015 和 mingw53_32。注意这里 mingw53_32 是 32 位Qt 5.9 系列没有官方 64 位 MinGW 套件。所以本标题默认是 32 位工具链后面所有路径、链接库名都按 32 位讲。想要 64 位就得自配 MinGW-w64 再用 Qt 源码自编老版本上这么折腾不划算常见做法是先 32 位跑通再考虑升级 Qt。对比项MSVC官方 OpenCV 包MinGW本标题路线链接库格式.lib.dll.a导入库C 运行库msvcp140.dlllibstdc-6.dll名字修饰MSVC ABIItanium ABI符号带下划线前缀Qt 5.9.6 对应套件msvc2015_64mingw53_32混用后果链接报错或运行期崩溃必须保证工具链同源2.2 安装四件套MinGW、Qt 5.9.6、CMake、Python先说 minGW 安装这是最容易走偏的一步。OpenCV 3.2.0 年代的脚本对老 mingw.org 的 GCC 4.x 已经不太友好部分头文件缺失会导致编译到一半崩掉。常见做法是用 MinGW-w64 体系而 Qt 5.9.6 安装器里自带的 MinGW 5.3.0 32 位就是用这套体系打包的路径一般在C:\Qt\Qt5.9.6\Tools\mingw530_32。直接用这个省掉 GCC 版本对不上的玄学问题。Qt 5.9.6 安装时勾选Qt 5.9.6里的MinGW 5.3.0 32-bit和Tools里的MinGW 5.3.0这两项缺一不可前者是库后者是编译器。CMake 版本我习惯压在 3.10 到 3.18 之间3.12 最稳。新版 CMake 跑 OpenCV 3.2.0 的问题不是不能用而是会冒出一堆 policy 提示老项目不值得为省一次安装去冒险。路径规范在这条路线里是硬要求OpenCV 源码解压到C:\opencvQt 装在C:\Qt\Qt5.9.6全路径不允许出现空格和中文。MinGW 的 make 脚本和 OpenCV 3.2.0 的 configure 阶段对带空格的路径处理得很糙Program Files这种路径会导致 cmake 传参时引号错位后面一堆诡异报错。Python 不是必需只要你不编 python 绑定装不装无所谓。2.3 验证命令行环境gcc、qmake、cmake 三条指令装完后不要直接进 CMake先把三件套在命令行里确认一遍。最简单的方式是用开始菜单里的“Qt 5.9.6 for Desktop (MinGW 5.3.0 32-bit)”快捷方式打开命令行它会自动把 MinGW 和 Qt 的 bin 目录配进 PATH。如果你更习惯自己开的 cmd就手动把三个目录加进系统 PATHC:\Qt\Qt5.9.6\Tools\mingw530_32\binC:\Qt\Qt5.9.6\5.9.6\mingw53_32\binCMake 安装目录的 bin然后在命令行里逐条验证where gcc g mingw32-make gcc --version qmake -v cmake --version第一条where是确认当前 PATH 里只有一套 gcc。很多人翻车是因为机器上装过别的 MinGW 或者 MSYS2where gcc一查出来两三个路径CMake 探测编译器时抓到旧版本编到一半报错再回头查就费劲了。gcc --version应当显示 5.3.0 或接近的版本qmake -v应当指向C:\Qt\Qt5.9.6\5.9.6\mingw53_32\bin。这两条输出对上了环境才算过关。cmake 版本看个大概即可3.12 左右就没问题。这里有个小细节验证时如果gcc能跑但mingw32-make找不到说明 PATH 里只进了编译器的 binmake 和编译器其实在同一个目录补上就行。如果qmake报的不是 Qt 5.9.6 的路径多半是 PATH 里先撞上了其它 Qt把顺序调一下确保 Qt 的 bin 在最前面。3. CMake 配置让 OpenCV 3.2.0 认到 Qt 5.9.6 的关键开关3.1 生成器与编译器设定MinGW Makefiles GCC 5.3CMake 和 MinGW 配合的常规做法是指定MinGW Makefiles生成器。如果不指定CMake 在 Windows 上默认会找 Visual Studio生成出来的是 .sln 工程跟 MinGW 一点关系都没有。命令行里加上-G MinGW MakefilesCMake 就会生成一套能被 mingw32-make 直接执行的 Makefile。这里有个前提CMake 探测编译器靠的是 PATH所以前面第 2.3 节的环境验证不是白做的。如果你在普通 cmd 里跑 cmakePATH 里没有 gccCMake 会报“找不到 C 编译器”。有时候明明 PATH 有CMake 还是抓错常见原因是机器上有多个 gccCMake 默认抓了第一个。遇到这种就用显式指定把编译器路径直接传给 CMakecmake .. -G MinGW Makefiles ^ -DCMAKE_C_COMPILERC:/Qt/Qt5.9.6/Tools/mingw530_32/bin/gcc.exe ^ -DCMAKE_CXX_COMPILERC:/Qt/Qt5.9.6/Tools/mingw530_32/bin/g.exe上面是 cmd 的写法行尾用^续行在 bash 里把^换成\即可。-DCMAKE_C_COMPILER和-DCMAKE_CXX_COMPILER是让 CMake 跳过探测、直接用指定编译器。注意 gcc.exe 和 g.exe 必须写全名只写gcc在某些 CMake 版本下会重新走 PATH 查找又回到多版本打架的局面。这一对参数一旦写进 CMakeCache之后反复重跑 configure 都会沿用除非删掉 build 目录重来。3.2 CMAKE_PREFIX_PATH 与 WITH_QT让 Qt5 被找到OpenCV 3.2.0 的 highgui 模块支持 Qt 后端但前提是 CMake 能通过find_package(Qt5)找到你那个 mingw53_32 的 Qt。find_package 靠的是CMAKE_PREFIX_PATH这个路径如果指错90% 会报Could not find a package configuration file provided by Qt5。指错的方向多半是把路径写到了C:\Qt\Qt5.9.6\5.9.6\msvc2015_64那是 MSVC 套件就算找得到也是错的东西。完整的 configure 命令如下建议直接在C:\opencv\build目录下执行cmake .. -G MinGW Makefiles ^ -DCMAKE_BUILD_TYPERelease ^ -DCMAKE_PREFIX_PATHC:/Qt/Qt5.9.6/5.9.6/mingw53_32 ^ -DWITH_QTON ^ -DWITH_OPENGLON ^ -DWITH_IPPOFF ^ -DWITH_MSMFOFF ^ -DBUILD_TESTSOFF ^ -DBUILD_PERF_TESTSOFF ^ -DBUILD_opencv_pythonOFF ^ -DBUILD_SHARED_LIBSON逐个说参数。CMAKE_PREFIX_PATH指向 Qt 套件根目录注意用的是正斜杠CMake 在 Windows 下也认正斜杠能少很多转义问题。WITH_QTON打开 highgui 的 Qt 后端这决定了你后面 imshow 弹窗用的是 Qt 绘图而不是老的 Win32 窗口。WITH_OPENGLON是配套项Qt5Gui 的渲染依赖 opengl32不开的话 Qt 后端在运行期可能退化窗口弹出来却是黑屏。WITH_IPPOFF很关键Intel IPP 的预编译库是 MSVC ABIMinGW 链接必炸直接关掉省事。WITH_MSMFOFF同理Media Foundation 是微软的媒体后端只支持 MSVCMinGW 下默认开启反而会在 cmake 阶段报找不到相关库。测试模块建议全关。BUILD_TESTSOFF和BUILD_PERF_TESTSOFF不只是省时间更是躲坑opencv_ts 模块在 MinGW 下的兼容性一直不太好编到那里报错的人不在少数。BUILD_opencv_pythonOFF是因为 3.2.0 的 python 绑定在 MinGW 下要额外处理 Python 库的 ABI你用不上就关。BUILD_SHARED_LIBSON保持默认编出动态库发布时几个 dll 拷走就行比静态库省心。3.3 按需关掉的模块你不需要的模块清单除了上面这些开关还有几个模块按需处理。BUILD_opencv_appsOFF关掉自带的小工具它们对一般项目没用MinGW 下偶尔还会因为 printf 格式串的问题编不过。BUILD_opencv_javaOFF同理不做 JNI 就关。如果你确定自己的项目不需要视频读写WITH_FFMPEGOFF可以省掉一大块时间但要注意OpenCV 3.2.0 在视频这块依赖一个独立的opencv_ffmpeg320.dll配置时开着 WITH_FFMPEG 会在编译阶段自动下载它到 bin 目录关掉的话 VideoCapture 直接用不了取舍看需求。还有两个常见选择我这里单独说明。BUILD_opencv_worldON会把所有模块合成一个 opencv_world320.dll链接时只写一个 -lopencv_world320 确实清爽但 MinGW 下 3.2.0 的 world 模式偶发内部符号错乱我个人不推荐在这条路线上开宁可多写几个 -l 参数。另一个是 opencv_contrib 扩展模块如果你要 SURF、SIFT 这些 non-free 算法去 GitHub 下载对应 3.2.0 tag 的 opencv_contrib然后在 cmake 里加一行-DOPENCV_EXTRA_MODULES_PATHC:/opencv_contrib/modules前一步的 cmake 缓存不会自动带上这个所以要在第一次 configure 时就加进去改模块路径最好的办法就是删掉 build 目录重新来。这也是这条路线的一个小习惯改配置前先想清楚CMake 缓存虽然能改但旧模块的编译产物会残留出问题更难定位。4. 编译与收尾mingw32-make 参数、产物与 Qt 集成4.1 开始编译多核参数与日志判断configure 顺利完成之后编译就是用 mingw32-make 一条命令的事。我的习惯是先确认 CMake 输出的末尾出现了Configuring done和Generating done并且 Qt 相关那几行显示的是Qt5Core: YES、Qt5Gui: YES、Qt5Widgets: YES再进行编译。这一步看走眼后面白编半小时。mingw32-make -j4-j4是并行编译的任务数4 个任务对双核四线程的机器比较合适内存小的机器降到 -j2。MinGW 的 make 对-j的支持比 Visual Studio 的 msbuild 稳不会出现半路卡死但并行任务开太多偶尔会有个别模块因为头文件生成时序问题报错重跑一遍 make 往往就过了。编译输出是模块一个接一个的Linking CXX shared library和Built target opencv_xxx看到opencv_core、opencv_imgproc这些核心模块先出来说明一切正常。这条路线第一次全量编译从零到全部模块32 位 Release 大概 20 到 50 分钟取决于 CPU。如果中间某个模块报错make 会停在那里。这时候注意看报错里是哪个 .cpp 文件以及它的模块前缀因为 3.2.0 的源码在 GCC 5.3 下有个别 C11 语法兼容问题常见的修法不是去改源码而是找到报错的模块用 cmake 关掉或者换一种编译方式比如 GUI 模块有问题就检查 WITH_QT/WITH_OPENGL 的搭配。硬啃源码改 OpenCV 的大坑非必要不碰。4.2 产物说明bin 目录、dll.a 导入库与头文件编完之后C:\opencv\build里出现的三样东西是后面集成要用的。很多人只盯着 bin 下面的 dll忘了 lib 下的导入库和 include 下的头文件集成时少一样都链不过。路径内容用途C:\opencv\build\includeopencv2 头文件含 cvconfig.h编译期 include 路径C:\opencv\build\binopencv_core320.dll、opencv_highgui320.dll 等运行期 dll需在 PATH 或 exe 旁C:\opencv\build\liblibopencv_core320.dll.a 等导入库链接期 -L 和 -l 使用头文件这里有个细节OpenCV 源码里也有一份 include但 build\include 下多了一个opencv2/cvconfig.h这是 CMake 根据你的开关生成的配置文件很多宏定义只有它才有。所以 include 路径必须指向build\include而不是源码目录。导入库的命名规则要留意。MinGW 生成的导入库是libopencv_core320.dll.a其中模块名后面的 320 是 OpenCV 3.2.0 的版本号。如果同时编了 Debug 版文件名会变成libopencv_core320d.dll.a多了个 d 后缀链接时写错就没有这个库。这也是很多初学者链不过的隐蔽原因教程里写的是 Release 的库名自己却编了个 Debug。4.3 在 Qt .pro 里接入 OpenCVINCLUDEPATH 与 LIBS 写法回到 Qt Creator打开你的工程文件 .pro把 OpenCV 的路径加进去。以读图和简单显示为例需要 core、imgproc、highgui 三个模块写法如下INCLUDEPATH C:/opencv/build/include LIBS -LC:/opencv/build/lib \ -lopencv_core320 \ -lopencv_imgproc320 \ -lopencv_highgui320-L指定链接库目录-l指定库名。注意库名不带 lib 前缀和 .dll.a 后缀MinGW 的链接器会自动匹配libopencv_core320.dll.a。这三个模块的依赖顺序其实无所谓MinGW 支持循环依赖解析但如果你的工程里同时用了 Qt 的 widgets记得QT widgets也要写否则 highgui 的 Qt 后端需要的 Qt5Widgets 头文件会找不到。链接通过只是第一步运行期才是 MinGW 路线的重头戏。程序跑起来之前编译器路径和库路径又得重现一次OpenCV 的 dll 要让 exe 能找到常见做法有两个。开发阶段把C:\opencv\build\bin加进系统 PATH发布阶段把用到的opencv_*.dll连同 MinGW 运行库libgcc_s_dw2-1.dll、libstdc-6.dll、libwinpthread-1.dll一起拷到 exe 同目录。这几个 MinGW 运行库经常被漏掉程序在你机器上能跑换一台机器就报“找不到 libstdc-6.dll”这是血泪经验。5. 避坑清单OpenCV 3.2.0 MinGW 编译期与运行期的 5 个经典翻车点5.1 CMake 找不到 Qt5Core_DIR 或 Qt5::Core target现象configure 阶段报Could NOT find Qt5Core或者更具体一点Qt5Core_DIR-NOTFOUND但你的 Qt 明明装得好好的。原因CMAKE_PREFIX_PATH没指对套件根目录或者根本没指。CMake 在 Windows 下不会自动扫 Qt 安装路径它只认这个变量。另一个隐蔽情况是 PATH 里有其它 Qt 的 binCMake 的 FindQt5 脚本也会去 PATH 里找 qmake结果版本对不上。解决把-DCMAKE_PREFIX_PATH严格指向C:/Qt/Qt5.9.6/5.9.6/mingw53_32确认这个目录下存在lib/cmake/Qt5/Qt5Config.cmake。同时检查 PATH 里只有一套 Qt。改完删掉 build 目录重新 configure别在旧的 CMakeCache 上直接加参数不干净。5.2 opencv_ts 编译崩在系统头文件现象前面模块都编得好好的编到 opencv_ts 时突然报一堆 C 模板错误比如 gtest 相关的.h文件里出现不认识的std::符号或者min/max宏冲突。原因opencv_ts 是测试模块它内部依赖 Google Test 的旧版本代码这套代码在 GCC 5.3 的 MinGW-w64 下兼容性很差加上windows.h里的min/max宏污染编译期就炸了。这个模块对正常项目毫无价值属于白挨的坑。解决configure 时-DBUILD_TESTSOFF和-DBUILD_PERF_TESTSOFF都带上直接跳过整个 ts 模块。如果你之前没关现在也可以重跑一次 cmake 加上这两个开关增量编译会跳过 ts不用全部重来。强烈建议在第一次 configure 时就把这两个开关关掉等于吃后悔药。5.3 链接期 undefined reference 与 CRT 冲突现象自己的 Qt 工程链接时报成片undefined reference to __imp_...或者特定的__imp___iob_func之类的符号找不到。原因分三种最常见的是把 MSVC 编的 OpenCV 官方包里的 .lib 直接用在了 MinGW 工程里符号格式对不上第二种是一开始开了WITH_IPPONIPP 的预编译库也是 MSVC ABIMinGW 链接必炸第三种是 build 目录里 CMakeCache 记录的是旧的编译器路径中途换过 gcc 版本导致部分 .o 文件和新编译器不匹配。解决确认链接的是 build\lib 下的 .dll.a 导入库不是官方包的 .libWITH_IPPOFF必须带上如果中途换过编译器干脆删掉 build 目录重新 configure 再编译。排查__imp_这类错误时先用objdump -p libopencv_core320.dll.a看导入库里的符号表确认里面确实有你需要的导出符号这一步能快速区分是有符号缺失还是链接顺序问题。5.4 运行期找不到 opencv_ffmpeg320.dll 导致视频打不开现象cv::VideoCapture打开视频文件总是返回 false程序不报错、不崩溃但读到的帧全是空。检查 exe 目录dll 就在旁边还是不行。原因OpenCV 3.2.0 的视频后端 ffmpeg 是一个独立运行库opencv_ffmpeg320.dll它默认在 build\bin 下和opencv_videoio320.dll是两个文件。而且这个 dll 的文件名带版本号和 OpenCV 版本严格绑定你拿 3.4 的opencv_ffmpeg340.dll改个名塞过来也没用内部符号对不上。解决从C:\opencv\build\bin把opencv_ffmpeg320.dll复制到 exe 同目录或加入 PATH。注意 32 位和 64 位的这个文件名不一样32 位是opencv_ffmpeg320.dll64 位是opencv_ffmpeg320_64.dll别拿错。如果确定程序不需要视频读入configure 时直接-DWITH_FFMPEGOFF眼不见心不烦。5.5 Qt 版 highgui 窗口不弹出的黑匣子问题现象imshow执行了程序也没报错但窗口就是不出现或者窗口弹出来了里面一片黑滑动条、按键响应都没有。原因highgui 的 Qt 后端在运行期要加载 Qt 的平台插件qwindows.dll这个插件位于 Qt 套件的plugins\platforms目录。你的 exe 如果不在 Qt 环境下直接双击运行或者 PATH 里没有 Qt 的 plugins 目录Qt 后端加载不到平台插件就会静默失败。黑屏的另一个原因是WITH_OPENGLOFFQt5Gui 的渲染管线缺了 opengl32 适配会退化但退化后不一定报错表现就是窗口内容是黑的。解决开发阶段在 Qt Creator 里跑一般没事因为 Creator 会带环境脱离 Qt Creator 运行时把C:\Qt\Qt5.9.6\5.9.6\mingw53_32\plugins\platforms整个目录拷到 exe 旁边或者用 windeployqt 工具处理。黑屏的情况回到 CMake 把WITH_OPENGLON打开重编 highgui 模块。排查这类问题时先临时设置环境变量QT_DEBUG_PLUGINS1Qt 会在运行期把插件加载过程打到控制台是哪个插件没加载一目了然别凭感觉瞎猜。6. 进阶验证用 QImage 上屏与调用链检查6.1 最小 demo读图、转换、显示编译和链接都过了最后一步是写一个最小程序把 OpenCV 的 Mat 转到 QImage 上显示。这一步能同时验证 OpenCV 的读取、Qt 的 Widgets、highgui 的 Qt 后端三条链路是否都通。下面这个例子直接在 Qt Widgets 工程里跑#include QApplication #include QLabel #include QImage #include QPixmap #include opencv2/opencv.hpp int main(int argc, char *argv[]) { QApplication app(argc, argv); // 读图路径按你本机实际位置改 cv::Mat bgr cv::imread(C:/opencv/test.png); if (bgr.empty()) { return -1; } // OpenCV 默认是 BGR 顺序Qt 的 QImage 用 RGB cv::Mat rgb; cv::cvtColor(bgr, rgb, cv::COLOR_BGR2RGB); // 用 Mat 的数据构造 QImage注意 bytesPerLine 要按 Mat 的实际步长 QImage img(rgb.data, rgb.cols, rgb.rows, static_castint(rgb.step), QImage::Format_RGB888); // 必须深拷贝否则 Mat 析构后 QImage 指向野内存 QImage copy img.copy(); QLabel label; label.setPixmap(QPixmap::fromImage(copy)); label.resize(copy.width(), copy.height()); label.show(); return app.exec(); }这段代码有几个容易踩的点。cv::imread读到的是 BGR 顺序直接塞给 QImage 会红蓝互换所以中间要先cvtColor转成 RGB。QImage 的构造函数里rgb.step是 Mat 的行字节数这个值不一定等于cols * 3因为 Mat 可能有内存对齐所以必须用它而不是自己算否则图像显示出来会斜切。最后img.copy()一定要做img只是包了 Mat 的 data 指针Mat 出了作用域 data 就没了不拷贝就是读野内存这个坑藏得深画面花屏的时候先检查这里。6.2 验证链路三件事程序能弹窗显示图像之后按下面三件事确认你的环境是真的通了而不是碰巧能跑。第一脱离 PATH 验证 dll 依赖。把环境变量里的 OpenCV 路径和 Qt 路径临时移掉直接双击 exe如果能正常起来说明所有 dll 都拷贝到了 exe 旁边发布环境是完整的。跑不起来就看任务管理器里程序挂在哪个模块上缺哪个补哪个。这是最接近发布现场的验证方式。第二确认 highgui 用的是 Qt 后端。编译时开了WITH_QTON的 OpenCVimshow 默认走 Qt 后端但很多人编译完其实没验证过。一个简单的判断方法在窗口里拖动缩放Qt 后端的窗口行为和原生 Win32 后端明显不一样更严谨的做法是搜一下 build 目录里的 opencv 头文件配置打开opencv2/cvconfig.h查看HAVE_QT宏是否被定义成 1。有这个宏链接的才是 Qt 版 highgui。第三验证 32 位工具链的一致性。用任务管理器看进程架构或者用where gcc确认编译器是 Qt 自带那套这三个东西必须同为 32 位exe、opencv 的 dll、Qt 的 dll。混一个 64 位进来程序要么起不来要么起来后窗口渲染异常。这条路线的所有坑基本都是工具链不一致造成的检查顺序从上到下走一遍问题就限定了。我现在的习惯是拿到任何一套带“Qt OpenCV”的老代码先问三个问题Qt 套件是 MSVC 还是 MinGW、OpenCV 是谁编的、两个的位数是否一致。三条对不上后面的编译跑起来大概率白干。这套环境配好之后我留了一整套 dll 备份目录方便之后换机器快速复现。编译这条链路的经验本质上就一句话编译器、库、运行库三者必须同源同构剩下的都是时间问题。希望帮到你。本文还有配套的精品资源点击获取