莫魔墨1. 这需求看着简单，结果折腾了我三天
事情起因其实很普通。有阵子我想在 Windows 上写个 C++ 的小工具，处理一些图像数据，核心就是读图、灰度化、边缘检测这一套。OpenCV 自然是首选，编辑器我早就习惯用 VSCode 了，C/C++ 扩展装好，配个 MinGW 编译器，加上 vcpkg 做包管理，这套组合光是听起来就非常"轻量、开源、极客"。我当时对 Visual Studio 的印象还停留在"臃肿、启动慢、装完占好几个 G"的老黄历上，所以第一反应就是：能用 VSCode 解决的事，绝不碰 VS2022。
而且说实话，我是从 Linux 下的 gcc/clang 工作流转过来的，命令行编译、Makefile、CMake 这一套我熟得很。MinGW 对 Windows 下的开发者来说就像一个"回家通道"，g++ 的编译参数、链接器报错格式、甚至是文件路径里的盘符处理，都让我觉得比 MSVC 亲切。加上当时网上搜 OpenCV 安装教程，十个里有八个在推 VSCode + MinGW 组合，看起来这条路线已经被无数人验证过了，我不可能踩出什么新坑。
但现实是，我在这条路上整整折腾了三天。第一天在 vcpkg 的 triplet 和依赖编译里打转，第二天面对一排排 undefined reference 发懵，第三天开始怀疑人生。最后我坐下来认真想了一个问题：我到底是在追求什么？是追求 VSCode 这个编辑器，还是追求 MinGW 这个编译器？如果我只是想要一个轻量编辑器，为什么不在保留 VSCode 的同时，把编译工具链换成 MSVC？想到这一步，事情突然就通了。
所以这篇文章不是什么教程，而是我完整踩坑后的复盘。我会把 vcpkg 装 OpenCV 时那些坑一个个摊开讲清楚，也会说明白为什么 MinGW 和 OpenCV 在 Windows 上总是"差口气"，以及最终我为什么选择装 VS2022 的 Build Tools，而不是完整版 IDE。如果你是刚想在这条路上走一遍的开发者，希望这篇能帮你省下那三天。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 目标明确：VSCode 当编辑器，vcpkg 管依赖，MinGW 当编译器
先把我最初的规划摆出来。目标是在 Windows 10/11 上，用 VSCode 作为主要开发环境，通过 CMake 构建一个能调用 OpenCV 的 C++ 程序。工具链有三样：VSCode 装 C/C++ 扩展和 CMake Tools 扩展；编译器用 MinGW-w64 8.1.0；包管理用 vcpkg，用来安装 OpenCV 以及其他图像处理可能用到的库。这组合在 VSCode 的很多教程里都有，看起来足够经典。
MinGW-w64 的安装倒是挺顺利。网上找的压缩包，解压后把 bin 目录加进 PATH，在终端里输入 g++ --version 能看到版本信息，就可以编译 Hello World 了。VSCode 里配置编译任务（tasks.json）和调试配置（launch.json）也很快，关键是设置对编译器路径和 miDebuggerPath 指向 gdb.exe 的位置。
然后到了 vcpkg。这里有个最基础但也最容易忽略的点：vcpkg 默认的 triplet（三元组）是针对 MSVC 的。也就是说，如果你不指定任何 triplet，直接跑：
code复制vcpkg install opencv
vcpkg 会默认使用 x64-windows 这个 triplet，它背后调用的是 MSVC 的 cl.exe。如果系统里没装 Visual Studio 或 Build Tools，vcpkg 就会在编译阶段报错，说找不到 cl.exe 或者环境变量没有初始化。我第一次就是直接踩了这个，折腾半天才意识到：不是 OpenCV 装不上，是 vcpkg 在等一个我没准备好的编译器。
于是我在后面补上了 MinGW 对应的 triplet：
code复制vcpkg install opencv:x64-mingw --recurse
这里 x64-mingw 表示使用 64 位 MinGW 工具链，--recurse 表示同时递归安装所有依赖。命令看起来没错，但接下来的事情，才真正让我意识到这条路远比想象中复杂。
2.1 为什么 vcpkg 默认不认 MinGW
先解释清楚 vcpkg 的 triplet 机制。vcpkg 本质上是一个源码包管理工具，它从代码仓库拉下来指定库的源码，然后在你本机上编译成库文件（静态库 .lib / .a，或动态库 .dll / .so），再生成头文件和 CMake 配置文件。由于 Windows 上编译器生态分两派（MSVC 和 MinGW-gcc），同一份源码编译出来的库，内部符号规则不同，链接方式也不同，所以 vcpkg 必须通过 triplet 来区分。
常见 triplet 有这么几个：
x64-windows：最常用，面向 MSVC 编译器，动态链接x64-windows-static：面向 MSVC，静态链接x64-mingw-dynamic：面向 MinGW，动态链接x64-mingw-static：面向 MinGW，静态链接
vcpkg 官方对 x64-windows 的维护力度最大，因为大多数 Windows 用户都用 MSVC。而对 MinGW 的 triplet，虽然存在，但 OpenCV 这种大库的依赖链特别长，任何一个依赖在 MinGW 编译环境下出问题，整个安装就会卡住。这也是为什么很多人最后安装失败，不是 OpenCV 本身的问题，而是依赖里的某个小库跟 MinGW 八字不合。
2.2 OpenCV 的依赖链有多恐怖
OpenCV 在 Windows 上不是孤立的一个库。完整安装时，vcpkg 会拉取并编译一堆依赖，包括但不限于：
- ffmpeg（视频编解码）
- protobuf（dnn 模块）
- tbb（并行计算）
- zlib、libpng、libjpeg、libtiff（图像格式支持）
- openjpeg（JPEG 2000）
- quirc（二维码）
- 以及其他小工具库
每个依赖都要从源码 CMake 一次、编译一次。在 MinGW 环境里，整体编译时间随便就是三四个小时起步。我那次装到一半，protobuf 因为网络问题下载失败，vcpkg 直接中断。重新跑的时候它又开始从头编译已经完成的部分，前面的进度全部白费。
这里有一个实际现象值得留意：vcpkg 的编译过程对网络要求很高，依赖源码包经常需要从 GitHub 等外部地址拉取。如果网络不稳定，下载就会失败。vcpkg 虽然有重试机制，但有时候连续失败几次它就直接退出了。
后来我学到一个操作：先单独安装几个容易失败的依赖，比如：
code复制vcpkg install protobuf:x64-mingw --recurse
等这些底层依赖编译好了，再安装 OpenCV，能减少很多整体失败的概率。但即便如此，MinGW 下 OpenCV 的编译仍然不保证 100% 成功，尤其是 dnn、cuda 相关模块。网络上很多反馈也印证了这一点：OpenCV 的某些模块在 MinGW 下编译不过，官方也没有精力去专门适配。
3. 真正致命的是 ABI 不兼容：MinGW 和 MSVC“各说各话”
如果说上面那些只是时间成本问题，那接下来这个问题就是根本性的了。我在 vcpkg 里折腾了很久，终于装出来一份带 x64-mingw 标识的 OpenCV，然后高高兴兴地写了一个测试程序：
cpp复制#include <opencv2/opencv.hpp>
#include <iostream>
int main()
{
cv::Mat img = cv::imread("test.jpg");
if (img.empty())
{
std::cout << "image load failed" << std::endl;
return -1;
}
cv::Mat gray;
cv::cvtColor(img, gray, cv::COLOR_BGR2GRAY);
cv::imwrite("gray.jpg", gray);
std::cout << "done" << std::endl;
return 0;
}
CMakeLists.txt 按 vcpkg 的标准套路写：
cmake复制cmake_minimum_required(VERSION 3.20)
project(opencv_test)
set(CMAKE_TOOLCHAIN_FILE "C:/vcpkg/scripts/buildsystems/vcpkg.cmake")
find_package(OpenCV REQUIRED)
add_executable(opencv_test main.cpp)
target_link_libraries(opencv_test PRIVATE ${OpenCV_LIBS})
CMake 配置阶段正常，find_package(OpenCV) 也能找到库。但一到编译链接阶段，g++ 给我甩了一大片波浪号，核心报错都是这种格式：
code复制undefined reference to `cv::imread(std::string const&, int)'
undefined reference to `cv::cvtColor(cv::_InputArray const&, cv::_OutputArray const&, int, int)'
当时我的反应是：怎么可能？OpenCV 的库文件明明在 vcpkg 目录里躺着，目标和函数名都看得见，为什么链接器说找不到？
3.1 ABI 是什么，为什么它决定了 MinGW 和 MSVC 互不兼容
这里要讲一个概念：ABI（Application Binary Interface，应用二进制接口）。如果编译器在生成目标文件（.o/.obj）时，对函数名进行不同的修饰规则（name mangling），那么即使你从同一个头文件出发，两个编译器产出的符号名字也是不一致的。g++ 和 MSVC 在这一点上差异很大。
具体表现就是：MSVC 编译出来的 opencv_world4100.dll 里，cv::imread 经过名字修饰后，符号名大概长这样：
code复制?imread@cv@@YA?AVMat@@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H@Z
而 MinGW 的 g++ 对同样的函数，产出的符号规则是：
code复制_ZNV2cv6imreadERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi
这两种符号对应的就是同一个函数，但在链接器看来是完全不同的两个名字。你拿着 MSVC 编译的导入库（.lib）去喂给 MinGW 的链接器，它根本认不出里面那些符号。反过来也一样。
这就是所谓的 ABI 不兼容。Windows 上的 C/C++ 生态被这种割裂分成两半：MSVC 派和 MinGW/Clang 派。你选了一个编译器，就必须用这个编译器编译出来的库，不能混着用。
3.2 那 vcpkg 装出来的“MinGW 版” OpenCV 为什么还是出问题
说到这里你可能会有疑问：既然 vcpkg 指定了 x64-mingw，它编译用的就是 g++，按道理符号应该对得上，为什么还会一堆 undefined reference？这个问题我也想了很多，实际原因有几个。
第一，OpenCV 这个 port 在 vcpkg 里的 CMake 构建脚本，某些模块的编译选项在 MinGW 下并没有被充分测试。比如 dnn 模块依赖 protobuf，而 protobuf 在 MinGW 下的符号导出可能不全；又比如有些模块在编译时，头文件里用了 MSVC 专属的 __declspec(dllexport) / __declspec(dllimport) 宏，而 MinGW 下 OpenCV 的 CV_EXPORTS 宏也会影响导入库的生成。如果 vcpkg 最终产出的导入库（.dll.a）不完整，有些函数符号没有被正确导出，链接阶段自然就找不到了。
第二，库的命名和链接参数不匹配。vcpkg 为 MinGW 生成的 OpenCV 导入库文件名，和 MSVC 版本差异挺大。MSVC 版通常叫 opencv_world4100.lib，MinGW 版是 libopencv_world4100.dll.a。如果直接手写 -lopencv_world4100 之类参数，g++ 会去找 libopencv_world4100.a 或者 opencv_world4100.dll.a，大概率找不到，然后报错。只有通过 CMake 的 find_package 生成的链接命令，才会自动带上正确路径和文件名，但前提是 OpenCVConfig.cmake 在 MinGW 环境下被正确识别。这一步在 vcpkg 里经常不完美。
第三，运行时的问题比链接问题更隐蔽。就算你运气好，链接过了，程序一运行就崩溃，那也是可能的。MSVC 和 MinGW 的 C++ 标准库实现不同，异常处理机制不同，甚至某些内部对象的内存布局都有差异。一个用 MSVC 编译的 DLL，如果内部抛出一个异常跨模块传到了用 MinGW 编译的主程序里，异常能不能被正确 catch 都是个问题。OpenCV 官方发布的预编译 DLL 全部基于 MSVC，这就决定了你最好也使用 MSVC。
3.3 用 dumpbin/objdump 验证符号不匹配
为了彻底搞清楚，我还特意用工具看了一下库文件的符号表。MSVC 环境里有 dumpbin 命令：
code复制dumpbin /exports opencv_world4100.lib | findstr imread
MinGW 环境里有 objdump：
code复制objdump -p libopencv_world4100.dll.a | grep imread
两者输出的符号名完全就是两套体系。看到这些输出的时候，我才终于死心：这不是我配置错了，而是编译器世界的底层规则决定了这条路走不通。知识本身总是可靠，只要你愿意花时间验证它。
4. VS2022 才是 OpenCV 在 Windows 上的“本命”编译器
在折腾的第三天，我做了一个简单的思维实验。OpenCV 官方在 Release 页面提供的 Windows 预编译包，文件名里写的是什么？是 OpenCV-4.10.0-windows.exe，它解压出来以后，里面有个 build 目录，子目录包括 x64/vc16、x64/vc15，分别对应 VS2019（v142）和 VS2017（v141）工具集。最新版也有 x64/vc17 对应 VS2022。你看，官方压根就没提供过 MinGW 的 Windows 预编译包。
为什么会这样？第一，用户量。在 Windows 上做 C/C++ 开发的，绝大多数用的是 Visual Studio 工具链，企业里、教学里、游戏公司里都是如此。OpenCV 团队只要维护一套 MSVC 预编译包，就能覆盖绝大多数用户。第二，CMake 的 Windows 生成器默认就是 Visual Studio，编译 OpenCV 源码最顺滑的路径就是 MSVC。第三，MSVC 运行时（vcruntime140.dll）在 Windows 系统上几乎是标配，微软官网也能下到独立的运行时安装包，分发成本极低。
所以，"OpenCV 官方根本不 care MinGW" 这个事实，就决定了你在 Windows 上想省心，必须跟 MSVC 走。你要么用官方预编译包，要么用 vcpkg 的 x64-windows triplet，几乎没有第三个选项。如果非要在 MinGW 上跑 OpenCV，那就只能借助 MSYS2 的软件仓库，那里有人专门用 MinGW-w64 编好了 OpenCV 的二进制包，这条路后面我会细说。
4.1 MSVC 与 OpenCV 预编译包的“无缝连接”体验
VS2022 的真正优势，不在于那套 IDE 界面，而是它自带的 MSVC 工具链（cl.exe 编译器、link.exe 链接器、nmake 等）跟 OpenCV 官方预编译包天然匹配。
具体来说，我用 vcpkg 重新执行了一次安装：
code复制vcpkg install opencv:x64-windows --recurse
这次跟之前 MinGW 时的体验完全不同。vcpkg 直接从二进制缓存里把预编译好的 OpenCV 拉下来（x64-windows 库里早就有了大量预编译产物），几分钟就完成了，不需要从头编译 ffmpeg、protobuf。如果你的 vcpkg 是刚克隆的，就算是源码编译，MSVC 环境下 OpenCV 的编译成功率也远高于 MinGW，十几分钟到半小时能搞定，因为所有依赖的开发团队基本上都在 CI 里验证过 MSVC 构建。
然后我在 VSCode 里重新配置 CMake Tools，让它使用 Visual Studio 2022 生成器，再写一个测试程序编译，整个过程顺滑得让我怀疑人生。之前用 MinGW 时，链接阶段刷屏的 undefined reference 全部消失，find_package(OpenCV REQUIRED) 一次通过，程序运行正常，cv::imread 读图、cvtColor 转灰度、imwrite 保存，一步到位。
4.2 VS2022 的“全宇宙最不缺的头文件路径和库路径”
还有一个很实际的体验：Windows SDK 从这套工具链里带出来的接口、头文件、库文件环境，对于各种第三方库来说几乎是标准答案。比如你要调用 Windows API 操作摄像头或者窗口，MSVC 的 Windows SDK 头文件天然可用。gcc 系虽然也能调，但总会有一些宏定义、__declspec 修饰符解析、宽字符支持方面的差异。
另外，MSVC 的调试体验是有明显优势的。VSCode 的 C/C++ 扩展里，调试器选择 cppvsdbg 时，针对 MSVC 编译产物的调试信息（PDB）解析最完整，变量查看、调用栈、断点命中都比 gdb 在 MinGW 下要顺滑很多。如果你用 gdb 调试 MinGW 程序，有时会碰到断点偏移、符号加载异常的问题，处理起来真的很花时间。
4.3 社区版免费，而不是网上流传的那些“密钥”
这里要顺带澄清一个很多人关心的问题：VS2022 到底要不要钱？其实微软提供的社区版（Community Edition）对个人开发者、学生、开源项目作者和小团队是完全免费的。你不需要去搜什么产品密钥，官网下载 Visual Studio Community 2022，安装时勾选“使用 C++ 的桌面开发”，就可以正常使用。热搜词里出现"vs2022产品密钥"，我猜不少人是被老版本的破解风气带偏了。实际上社区版个人使用没有功能限制，唯一的限制条款是针对大型企业的使用场景，这对绝大多数人都够用了。
当然，我的目标是轻量，所以最终我并没有安装完整的 VS2022 IDE 和所有组件，而是只安装了 Build Tools。这个我放到后面单独说。
5. 如果你真咬着牙要 MinGW，这三条路可以救急
看到这里如果你还是坚定地说："不行，我就想用 VSCode + MinGW，我不想装 VS2022。"好吧，那我分享几个实际可行的备选方案，它们比 vcpkg 硬碰硬要省心不少。
5.1 方案一：MSYS2 + pacman 直接装预编译的 OpenCV
MSYS2 是一个在 Windows 上模拟类 Unix 环境的软件发行版，它自带的 pacman 包管理器里有大量 MinGW-w64 构建的预编译库。要装 OpenCV，只需要在 MSYS2 的终端里执行：
code复制pacman -S mingw-w64-x86_64-opencv
这条命令会从 MSYS2 的软件源下载已经编译好的 OpenCV 二进制包，安装速度取决于你的网速，一般几分钟搞定，完全不用从源码编译。它的可执行文件、DLL、头文件会放到 MSYS2 安装目录下的 mingw64 里面。
为什么这条路比 vcpkg 的 x64-mingw 好？因为 MSYS2 生态里的这套 OpenCV 是社区维护者用固定的工具链版本持续构建的，库和依赖之间的版本配对关系经过了验证。你不小心装到一个"缺模块"或者"符号导出不全"的版本的概率低得多。而且 pacman -S 是预编译安装，不需要本地编译，所以不存在 vcpkg 那种"编译到一半失败了"的问题。
用 MSYS2 的 g++ 编译你的 CMake 项目时，记得把 CMake 的生成器指定为 "MinGW Makefiles" 或 "Ninja"，并且让 CMake 能找到 MSYS2 的编译器。最简单的办法是在 MSYS2 的终端里运行 CMake，编译器的路径自动就在 PATH 里面：
code复制cmake -S . -B build -G "MinGW Makefiles"
cmake --build build
如果你只是写命令行小工具、不依赖 Windows GUI 或者摄像头直采，这个方案是最接近"VSCode + MinGW"理想状态的。
5.2 方案二：vcpkg 的 x64-mingw，但只装你真正需要的模块
如果你因为某些原因必须用 vcpkg，那也不是完全没有机会。问题是 OpenCV 的 port 默认是编译全部模块（contrib 不算，但核心模块非常多），依赖链拖得很长。你可以在安装时通过特性开关，只编译你需要的模块部分。
例如，如果你的项目只需要 imgcodecs、imgproc、core 这几个基础模块，不需要 dnn 的深度神经网络推理，可以通过修改 port 的 feature 选项来缩减依赖范围。vcpkg 安装支持 --editable 或者直接改写 ports/opencv4/ 目录下的 manifest 文件。不过这种方式对新手不太友好，而且每次 vcpkg 更新端口文件后，这些修改可能会被覆盖。
我的建议是：纯 vcpkg + x64-mingw + 完整 OpenCV，如果你不是特别有耐心的编译爱好者，尽量别碰。它耗费的时间、电量、心情成本，远超"装个 VS2022 Build Tools"。
5.3 方案三：WSL2 里跑 Linux 版 OpenCV，再用 VSCode 远程连接
如果你只是做学习、图像算法验证，不一定要在 Windows 上编译树。VSCode 的远程开发插件（Remote - WSL）可以让你用 WSL2 里的 Ubuntu 环境写代码、编译、调试，OpenCV 在 Linux 下用 apt 安装极其简单：
code复制sudo apt update
sudo apt install libopencv-dev
WSL2 的 IO 性能虽然不如原生，但普通图像处理开发完全够用。VSCode 打开本地文件夹后，右下角点一下"在 WSL 中重新打开"，整个界面没有任何变化，但底层的编译器、终端、调试器都已经切换到了 Linux 环境。这种方案的好处是彻底绕开了 Windows 上的 MinGW/MSVC 之争，你用 g++ 用得爽，OpenCV 的 Linux 版本也是官方支持最完善的。缺点是：如果你的项目需要调用 Windows 摄像头或者跟 Windows 桌面交互，这条路就不好使了。
6. 最后一锤定音：我只装了 VS2022 Build Tools，没装完整 IDE
把前面的坑全部趟完，我最终的选择是：保留 VSCode 作为编辑器，安装 VS2022 Build Tools（也就是 C++ 生成工具），用 MSVC 作为编译器，vcpkg 用默认的 x64-windows triplet。
这里有个很反直觉但又很合理的点：VS2022 Build Tools 不需要安装完整 IDE。它只是一个命令行工具集，包含了 MSVC 编译器、Windows SDK、CMake、以及 vcpkg 集成需要的一切。安装完成之后，VSCode 还是我的 "主界面"，但背后的编译器已经换成了 MSVC。这既满足了我"不要臃肿 IDE"的执念，又解决了 OpenCV 库链接的问题。
6.1 具体安装步骤和需要勾选的组件
下载 Visual Studio Installer 之后，选择"适用于 Windows 的 C++ 生成工具"这个工作负载，这是 Build Tools 的核心。如果是从零开始，建议至少勾选这几个组件：
- MSVC v143 - VS 2022 C++ x64/x86 生成工具
- Windows 10/11 SDK
- 适用于 Windows 的 C++ CMake 工具
- 测试工具核心功能（可选）
安装过程中会下载好几个 G 的文件。别被这个体量吓到，实际上装完以后它不用常驻后台，命令行工具直接可用。我在装完后显式将 vswhere 检测到的路径加入环境变量，这样 VSCode 的 CMake Tools 插件能自动找到 MSVC 工具链。
装完后，VSCode 里的 CMake Tools 插件会自动识别新的工具链。按 Ctrl+Shift+P，执行 CMake: Select a Kit，你会看到类似 Visual Studio Community 2022 Release - x86_amd64 或者 Visual Studio Build Tools 2022 Release - amd64 的选项，直接选它。这样 CMake 的生成器就是 Visual Studio 2022，编译和链接全程走 MSVC。
之后重新设置 vcpkg 的 triplet，在你的 CMakePresets.json 或者 CMake 命令里指定：
code复制cmake --preset=vs2022-release
或者在 CMakeLists.txt 里保持 CMAKE_TOOLCHAIN_FILE 指向 vcpkg，不额外指定 triplet，vcpkg 会默认用 x64-windows。之前的 OpenCV 依赖链在 MSVC 下瞬间变得温和，不需要从源码编译，直接拉取预编译产物，几分钟内就绪。
6.2 新的测试结果：从报错刷屏到一次通过
同样的测试代码，换到 MSVC 工具链后：
code复制cmake -S . -B build-vs2022
cmake --build build-vs2022 --config Release
这一条命令跑完，直接生成了 Release 版本的 exe。运行它，test.jpg 被正确读入，灰度图输出到了 gray.jpg。没有 undefined reference，没有奇怪的链接器错误，没有 DLL 找不到的运行时异常。整个流程顺畅到让我有点恍惚，原来不是这条需求难，而是我一开始选错了编译生态。
后来我又在 VSCode 里配好了 cppvsdbg 调试器，启动调试后断点准确命中，变量监视里 cv::Mat 的 rows、cols、data 都能直接查看，鼠标悬停在变量上也能看到结构体内容。这个调试体验比 MinGW + gdb 舒服得多，特别是 OpenCV 这种涉及大量复杂数据类型的库。
6.3 为什么说这是"编辑器轻量 + 编译器稳定"的最优解
很多人对 Visual Studio 有误解，觉得装它就等于开了一个大全套 IDE，内存吃满、启动缓慢。但实际上 Build Tools 就是把"编辑器"这个角色拆了出去，让 VSCode 做它擅长的事（文件管理、插件生态、远程开发、Git 集成），而编译器纯命令行工作，不占任何日常开销。这是一个"编辑器轻量 + 编译器稳定"的组合，兼顾了 VSCode 的体验和 MSVC 的兼容性。
如果你仍然喜欢 VSCode 的界面和快捷键，又希望 Windows 生态的库都能顺利使用，这个方案是我目前最推荐的。它不像纯 MinGW 那样常有第三方库兼容问题，又比完整 Visual Studio 少了很多用不到的组件，非常适合 C++ 开发者日常写小项目或者学习 OpenCV。
分享一个我现在很习惯的操作
最后说一点我个人的使用习惯。现在我在 Windows 上开发 C++ 项目时，默认使用一个 CMakePresets.json 文件，里面同时配置了 Debug 和 Release 两套 MSVC 预设，也不会去手动指定 MinGW 工具链。VSCode 里装好 CMake Tools 插件后，每次打开项目它会自动认到 VS2022 的 Kit，编译、运行、调试都不需要再手动敲命令。
如果只是临时跑一段 OpenCV 例程，不想建完整工程，我也会用 MSYS2 的预编译包应急，在那边终端里直接 g++ main.cpp -o test $(pkg-config --cflags --libs opencv4)，一行命令就能出结果。两条路并行，日常开发走 MSVC，临时验证走 MSYS2，基本覆盖了我遇到的所有场景。希望这份经历能让你少走一些弯路。