简介：这是一份面向Windows 10平台、使用MinGW编译器在Qt环境中开发OpenCV应用所需的OpenCV 4.5.5库文件压缩包。资源主要服务熟悉C++、希望在Qt Creator下集成OpenCV实现图像识别、物体检测、人脸识别等视觉功能的开发者，解决MinGW版OpenCV库编译配置困难的问题。压缩包共413个文件，大小17.54MB，以hpp与h头文件为主，同时包含xml模型/配置文件、a与dll链接库、exe工具、cmake配置脚本及多份license说明，覆盖OpenCV核心模块、DNN模块及第三方依赖，可直接用于项目链接与调试。已有549人浏览学习，配套目录结构清晰，提供core、dnn、imgproc、features2d等常用模块的库文件，开发者按MinGW套件配置Qt Creator后即可调用cv::Mat、cv::imread等接口编写图像处理程序，并进一步利用cv::dnn实现深度学习推理。
1. 为什么要自己编译一个OpenCV MinGW版本
先说结论：如果你用的是Qt Creator、CLion或Dev-C++这类基于MinGW工具链的开发环境，想在Windows上调OpenCV，直接从官网下载的预编译包多半用不了。这不是操作问题，是工具链的二进制兼容性问题。
OpenCV官网的Windows版本默认是用MSVC（Visual Studio编译器）编译的，链接的是MSVC的运行时库。而MinGW是GCC在Windows上的移植版本，使用的是自己的运行时库。这两者使用的C++ ABI、异常处理模型、标准库实现都不一样，直接拿到一起链接，根本过不去。哪怕运气好链接过了，运行起来大概率也是崩溃。
这时候你有两条路。一条是改用Visual Studio开发，另一条就是自己动手，用MinGW重新编译一份OpenCV。标题里这个windows_OpenCV_MinGW_lib_4.5.5.zip，其实就是一个已经被验证可用的编译产物。这篇文章我就把整个编译过程和踩坑经验完整写出来，覆盖从工具链准备、CMake配置、编译打包，到集成进CMake工程的完整流程，适合正在用MinGW工具链并需要OpenCV的C++开发者参考。
顺便说一句，我选择4.5.5这个版本，是因为它比较稳定。OpenCV从4.5.x开始，DNN模块的ONNX支持已经比较成熟，4.5.5又修正了此前几个版本的一些回归问题，整体构建体验在MinGW下也比较顺畅。后面4.6、4.7在编译时对C++标准要求更高，MinGW版本太老容易踩坑。
2. 工具链选型与编译方案
2.1 MinGW和MSVC到底差在哪里
很多新手不理解为什么要分这么清楚。我打个比方：MSVC和MinGW就像是两套不同的建筑标准，砖头尺寸都不一样。你用MSVC编译出的静态库（.lib），相当于按一种砖头规格盖的墙，MinGW这边按另一种规格砌墙，硬拼在一起当然对不上。
具体到技术层面，差异主要体现在三点：
- C++标准库不同。MSVC用STL，MinGW用libstdc++（和Linux上GCC一致），两者的
std::string内部布局完全不同，跨编译器传对象直接崩。 - 异常处理机制不同。MSVC默认用SEH，MinGW在64位下用SEH或DWARF，栈展开方式不一样。
- 符号命名规则不同。C++重载后的符号修饰规则有差异，链接器找不到符号就会报"undefined reference"。
所以如果你看到链接时疯狂报错，显示一堆带std::前缀的undefined reference，不用怀疑，就是工具链混用了。
2.2 工具链版本的选择
这一步直接决定后面能不能顺利编译，我的建议如下：
- MinGW-w64：建议用8.1.0或更高版本，不要用老的MinGW32（5.x的TDM-GCC之类）。64位环境下用
x86_64-posix-seh版本，其中posix指的是线程模型（支持std::thread），seh是异常处理模型。如果你的MinGW是win32线程模型，编译一些依赖C++11线程的模块会失败。 - CMake：3.16以上即可，建议用最新版。编译OpenCV用到的生成器是"MinGW Makefiles"。
- OpenCV源码：直接去GitHub下载4.5.5的source包，不要下载pre-built版本。
- Python：可选，但建议装一个。OpenCV编译时会自动探测Python并生成Python绑定，如果你不需要Python接口，后面CMake配置时直接关掉，省很多时间。
我本机使用的组合是：Windows 10 x64 + MinGW-w64 8.1.0 (posix-seh) + CMake 3.22 + OpenCV 4.5.5源码。这套组合编译很顺畅，后面所有步骤基于这个环境。
提示：MinGW-w64的安装路径千万别带空格和中文，建议直接放
C:\mingw64，否则CMake查找编译器时容易出各种诡异问题。
2.3 编译策略：全量编译还是精简模块
OpenCV有几百个模块，但大部分你其实用不到。全量编译也不是不行，就是慢，而且容易在无关模块上踩坑。比如opencv_contrib里的xfeatures2d模块在MinGW下偶尔有编译问题，java模块还要求本机装JDK，没必要。
我采用的策略是先关掉所有默认模块，再按需打开。核心模块（core、imgproc、highgui、imgcodecs、videoio、calib3d、features2d、objdetect、dnn、photo、stitching、video）是基本盘，全部保留。视频相关的FFmpeg支持默认是关的，如果你要读视频文件，在CMake配置时打开WITH_FFMPEG，前提是FFmpeg已经装好。这里有个取舍，下面细说。
3. 完整编译流程
3.1 CMake配置阶段详解
老规矩，先建一个工作目录。我习惯这样安排：
D:\opencv_build\ ├── opencv-4.5.5\ # 源码解压目录 ├── build-mingw\ # 编译输出目录 └── installed\ # 安装目录（最终产物）然后打开MinGW的终端（注意不是cmd，是MinGW自带的，或者在cmd里把MinGW的bin目录加到PATH），进到build-mingw目录执行cmake。以下是我经过多次测试后确定的最简配置：
cmake -G "MinGW Makefiles" \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=D:/opencv_build/installed \ -DBUILD_opencv_world=ON \ -DBUILD_EXAMPLES=OFF \ -DBUILD_TESTS=OFF \ -DBUILD_PERF_TESTS=OFF \ -DBUILD_JAVA=OFF \ -DBUILD_opencv_python2=OFF \ -DBUILD_opencv_python3=OFF \ -DWITH_OPENCL=OFF \ -DWITH_OPENGL=OFF \ -DWITH_QT=OFF \ -DWITH_FFMPEG=OFF \ -DWITH_MSMF=OFF \ ../几个关键参数解释下：
BUILD_opencv_world=ON：把所有模块编译成一个统一的opencv_world库。链接的时候只需要-lopencv_world一个库就行，省心。WITH_OPENCL=OFF：OpenCL运行时在MinGW下容易出兼容性问题，普通桌面应用用不到，关掉。WITH_FFMPEG=OFF：这个决定要不要支持视频文件读取。FFmpeg的MinGW版本需要自己单独编译，过程比较折腾。如果你的应用只处理图片，建议先关掉，后续需要再补。WITH_MSMF=OFF：Media Foundation是Windows的视频后端，在MinGW下的支持不好，关闭。BUILD_opencv_python3=OFF：这里需要注意的是，如果你是在Anaconda环境里配过OpenCV，再在C++环境编译时，CMake会自动探测到Anaconda的Python，然后给你生成一套可能用不了的绑定，甚至有概率把编译搞挂。干脆关掉。
如果你在用Qt做界面，WITH_QT=ON可以打开，这样highgui模块的imshow窗口会用Qt渲染，比默认的Win32原生窗口好看。但要求你本机装了Qt并设置CMAKE_PREFIX_PATH指向Qt的安装目录，配置复杂度上了一个量级。我建议第一轮编译先不开。
3.2 编译与安装过程
配置成功后，终端里会显示一大堆生成信息。确认一下末尾处没有红色的ERROR，然后执行编译：
mingw32-make -j8-j8是并行编译，数字不要超过CPU线程数的1.5倍。我本机是8线程，用-j8大约跑了20多分钟。如果你是用机械硬盘，建议降到-j4，否则磁盘IO会成为瓶颈，反而更慢。
编译过程中间会有几个模块报warning，比如libpng的某些告警，不用管，不影响使用。真正会中断编译的error一般集中在：
- 编译器版本太旧，C++11特性支持不全
- API和OpenCV新版本不兼容的第三方库（比如libjpeg-turbo）
- 磁盘空间不足
编译完成后，安装：
mingw32-make install这会把你配置时指定的CMAKE_INSTALL_PREFIX目录填充完整。最终installed目录的结构大概是这样的：
installed/ ├── include\ # 头文件，opencv2目录 ├── x64\mingw\ # 或直接lib/ │ ├── libopencv_world455.dll.a # 导入库（静态链接用） │ └── libopencv_world455.dll # 运行时DLL └── bin\ └── libopencv_world455.dll其实OpenCV在MinGW下默认生成的是动态库（DLL），.dll.a文件是链接用的导入库。它名字里带lib开头，很多人误以为是纯静态库，注意区分一下。
3.3 打包成可分发压缩包
到了这一步，你就可以把installed目录压缩成windows_OpenCV_MinGW_lib_4.5.5.zip了。但这里有个细节：直接压缩整个目录，压缩包会比较大，里面有大量不需要的cmake配置文件和pkgconfig文件。我的做法是只保留这几个核心部分：
include\ # 全部头文件 bin\ # 放DLL lib\ # 放导入库然后写一个README.txt，记录编译选项、MinGW版本、使用说明。这样压缩包体积能控制在80MB以内，分发起来也方便。
注意：
.dll.a是导入库而不是静态库。真正的全静态编译需要给CMake传-DBUILD_SHARED_LIBS=OFF，这样会生成libopencv_world455.a，运行时不需要带DLL，但exe体积会大不少，而且静态库的方式在MinGW下还要求额外链接一大串系统库，容易漏。如果你不是有洁癖，建议还是用DLL方案。
4. 集成到CMake工程
4.1 一个最小可用的CMakeLists.txt
装好之后，最关键的就是让项目能链接到这套库。下面是我一直在用的模板，多数情况直接抄就行：
cmake_minimum_required(VERSION 3.10) project(opencv_demo) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 指定OpenCV的安装路径 set(OpenCV_DIR "D:/opencv_build/installed") find_package(OpenCV REQUIRED) add_executable(demo main.cpp) # 如果这里用了Qt，还需要 include Qt 的相关模块 target_link_libraries(demo ${OpenCV_LIBS})注意OpenCV_DIR是OpenCV安装目录下lib/cmake/opencv4这个路径的父目录，因为OpenCV安装后会生成OpenCVConfig.cmake，find_package就是靠它来定位的。
4.2 运行时的DLL路径问题
在CMake生成的构建目录里直接运行demo.exe，大概率会提示找不到libopencv_world455.dll。这是因为程序启动时Windows会在当前目录、PATH、exe同目录这三个地方找DLL。
解决办法有三条：
- 把DLL复制到exe所在目录，简单粗暴。
- 把
installed/bin目录加到系统PATH环境变量，一劳永逸，但换机器还要再配。 - 在CMake里加一个自定义命令，每次构建后自动复制DLL：
add_custom_command(TARGET demo POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different "D:/opencv_build/installed/bin/libopencv_world455.dll" $<TARGET_FILE_DIR:demo>)我推荐第三种，自动化程度高，也不污染系统环境。
5. 常见问题与排查实操
5.1 编译阶段的典型报错
问题1：CMake提示找不到编译器
现象是执行cmake后报Could not find a C compiler。排查思路：确认MinGW的bin目录有没有加进PATH，用gcc --version能不能正常输出版本。如果gcc能运行但CMake还是找不到，检查是不是在普通的cmd里执行的（有的CMake Windows版与cmd中PATH刷新不即时），试着重开终端。
问题2：编译到30%左右报错，提示undefined reference to __imp_...
这个报错通常发生在链接第三方库时。常见原因是MinGW从8.0开始，链接选项变了。如果你是用老教程里的方法自己拼gcc命令链接OpenCV，建议改用CMake，让OpenCV的配置文件去处理链接参数。手动链接时漏了-lopencv_world455或者顺序不对，都会出现这种报错。
问题3：编译opencv_dnn模块时内存不足
DNN模块文件大，模板实例化多，编译时要吃很多内存。4GB内存的机器容易卡死。解决方法是把-j8改成-j2，同时关闭OPENCV_DNN_BUILD_TORCH_TEST等测试选项。如果还不行，就单独把DNN模块排除：在CMake配置里加-DBUILD_opencv_dnn=OFF。
5.2 链接阶段的常见坑
问题1：一堆undefined reference to std::__cxx11::basic_string
这说明你混用了不同版本的MinGW编译产物。比如OpenCV库是用MinGW 8.1编译的，但你的项目用MinGW 5.3编译，两者C++标准库的ABI不同。解决办法：统一工具链，确保编库和编项目的GCC大版本一致。
问题2：cannot find -lopencv_world455
CMake找到了OpenCV，但链接时找不到库文件。检查一下installed/lib目录下文件名结尾是.dll.a还是.a。如果你的库是纯静态编译的，文件是libopencv_world455.a，那么CMake里生成的OpenCV_LIBS路径没问题，但需要额外系统库。动态库方案下，记得确认DLL也一并被找到。
问题3：用了opencv_world库和模块库混用
如果你配置时没开BUILD_opencv_world=ON，那lib目录下是一堆libopencv_core455.dll.a、libopencv_imgproc455.dll.a这样的文件。这时链接要写多个-lopencv_core -lopencv_imgproc...。麻烦不说，还容易漏。建议统一用world模式。你自己分发windows_OpenCV_MinGW_lib_4.5.5.zip时，也建议明确写明是world模式还是分模块模式，避免使用者踩坑。
5.3 一些不太常见但确实会遇到的问题
Qt/CMake混用时的头文件冲突
如果你项目里又用Qt又用OpenCV，有时候会碰到qglobal.h和opencv2/core/types_c.h的某些宏定义冲突。这不是MinGW特有的问题，MSVC下也有。解决办法是确保先包含Qt头文件，再包含OpenCV头文件，或者定义QT_NO_KEYWORDS宏。
MinGW 8.1自带的winpthreads
你可能会发现编译链接成功后，运行时差一个libwinpthread-1.dll。这个小文件在MinGW的bin目录下，一部分OpenCV模块依赖线程库。分发时记得把相关DLL一起打包，否则用户拿到你的zip后，程序运行又报缺DLL。我习惯把所有依赖的DLL统一放到一个runtime目录：libopencv_world455.dll、libgcc_s_seh-1.dll、libstdc++-6.dll、libwinpthread-1.dll，一次放全。
6. 项目后续维护建议
这套编译产物我是按"一次编译，多处使用"的思路维护的。实际用下来，最舒服的方案就是把它当作一个内部工具包，存放路径保持固定，新项目只需要三行CMake引用就能启动开发。如果有新同事加入，直接把压缩包发过去，解压后改一下OpenCV_DIR路径就完事，不用重复踩编译的坑。
另外，如果你的应用后面开始对性能有更高要求，比如要把视频处理做成实时，那可以试着打开FFmpeg支持。编译FFmpeg的MinGW版本确实是个体力活，网上可以搜到现成的脚本，把ffmpeg的源码用同款编译器编好，然后再回过头来给OpenCV开WITH_FFMPEG=ON重新编一遍，操作方式和我上面写的步骤一样，多了一轮而已。
我自己在维护这个包的过程中，最大的体验是：别怕编译慢、别怕报错，OpenCV的CMake脚本已经写得相当成熟了，大部分报错都是环境问题而不是源码问题。把工具链的一致性保证好，这个包就是真正一劳永逸的。最后再把分发时务必带齐那几个DLL这件事强调一遍——这大概是我被问得最多的问题了。
以后如果再更新OpenCV版本，流程也是一样的，只是把源码版本号换一下，CMake配置保持不变，基本上十分钟内能编完。希望这份记录能帮你少走点弯路。
本文还有配套的精品资源，点击获取
