简介：面向 Visual Studio 2015 开发者的 OpenCV 3.2.0 编译整合包，同时纳入 opencv_contrib-3.2.0 扩展模块，无需自行下载源码、配置 CMake 与编译扩展库，即可获得完整视觉开发环境。3.2.0 版在图像处理、特征检测、DNN 深度学习等方面均有改进，contrib 中的 aruco、optflow、xfeatures2d 等可满足增强现实、光流估计、特征匹配等应用。压缩包共 456 个文件，整体约 28.3MB，以 280 个 hpp 和 57 个 h 头文件声明接口，配合 42 个 dll 动态库与 41 个 lib 静态库，另有 cmake 脚本与 xml 数据文件，保留构建配置信息，便于在 VS2015 中设置包含目录和链接依赖。已有 496 人学习下载，解压后可直接引用现成库文件投入项目开发，也可借助其中的配置文件理解 contrib 扩展模块的构建思路，适合图像处理、机器视觉方向的中级开发者快速搭建实验环境。

1. 为什么 opencv3.2.0 + vs2015 + opencv_contrib 要重编：官方包给不了的东西

刚接手老视觉工程时，最绕不开的编译任务就是把 opencv3.2.0+vs2015+包含opencv_contrib-3.2.0 这套组合自己编一遍。官方预编译包里只有主模块，SIFT、SURF、ArUco 这些扩展功能全在 opencv_contrib 里，而这恰恰是老代码调用最多的部分。与其四处找别人编好的包，不如在自己机器上把 CMake 到 VS2015 的整条链路走通。这篇文章写给要动手重编的人：版本配对、CMake 参数、VS 编译、坑点排查、可用性验证，按下面章节一步步来，基本一次能过。

2. 编译前准备：版本配对、VS2015 环境与下载检查

2.1 opencv-3.2.0 与 opencv_contrib-3.2.0 版本必须一致：CMake 靠路径识别模块

先理清两个仓库的关系。opencv 主仓库的 modules 目录下面是 core、imgproc、highgui 这些基础模块；opencv_contrib 是独立仓库，单独提供 aruco、bgsegm、xfeatures2d、ximgproc 等扩展模块。CMake 在配置 OpenCV 时，通过一个叫 OPENCV_EXTRA_MODULES_PATH 的变量去扫描 contrib 仓库的 modules 目录，把里面的模块当成主工程的扩展模块，一起生成 VS 工程和编译目标。

版本配对这件事没有讨价还价的余地。我见过拿 opencv_contrib-3.4.x 配 opencv-3.2.0 的情况，configure 能过，但编译到 contrib 模块里某个引用新头文件的源文件时直接崩，报错还是一个完全看不懂的模板展开错误。原因是 contrib 里的代码依赖主仓库的头文件和接口，版本差一两个大版本，接口就变了。强烈建议主仓库和 contrib 压缩包都下载 3.2.0 标签下的版本，解压后先确认目录名，再检查 modules 层级是否存在，这一步省后面所有事。

怎么判断 contrib 是否真的被 CMake 识别到了？configure 完成后，看输出窗口里有没有一行类似 “Extra modules: aruco bgsegm bioinspired ... xfeatures2d ximgproc” 的日志。看不到这一行，说明 OPENCV_EXTRA_MODULES_PATH 没有生效，就算后面 Generate 成功，生成的 VS 工程里也不会有 contrib 模块。

# 确认解压后的目录结构，modules 目录必须真实存在 Get-ChildItem D:\src\opencv_contrib-3.2.0\modules | Select-Object -First 10 Name

这条 PowerShell 命令只做一件事：确认 contrib 源码的 modules 目录下确实有子模块。如果这里列出来的是 build 目录、CMakeLists.txt 之类的东西，说明解压层级不对，后面填路径一定会填错。

2.2 VS2015 与 Win64 生成器：位数、v140 工具集、CMake 版本怎么配

VS2015 对应的 C++ 工具集是 v140，OpenCV 产物目录里常见的 vc14 也是指它。VS2017 是 vc15，VS2019 是 vc16。老工程锁在 vs2015，多半不是开发人员懒，而是项目里还有别的老库依赖这个工具集的运行时行为。所以编译 OpenCV 时也要跟着用 v140 工具集，不要图省事用 VS2017 打开工程再让它自动升级工具集，升级之后 OpenCV 源码本身可能没事，但你的老工程连接时可能因为运行时不匹配出现一堆怪问题。

用 CMake 生成 VS2015 工程时，生成器要选 “Visual Studio 14 2015 Win64”，不是默认的 “Visual Studio 14 2015”。前者生成 x64 平台工程，后者默认 Win32。位数错配的典型症状是：configure 全绿、生成也成功、编出来的库看着没问题，但你的 x64 程序去链接它时，链接器报一堆 LNK2019 无法解析的外部符号。这不是库坏了，是库编译时用的平台和你程序不一致。64 位还是 32 位，从 CMake 生成器到 VS 配置管理器，再到最终程序的平台，必须从头到尾保持一致。

CMake 版本这里有个容易忽略的点：不用追最新版。3.2.0 年代的 OpenCV 对当时的老版本 CMake 配合得最好，太新的 CMake 在遇到某些旧版if()语法和策略变化时，行为会和当年不一样，轻则多几个警告，重则在版本检查处直接报错。常见做法是装一个 3.10 到 3.18 之间的版本，既能识别 VS2015，又不至于引入太多新策略。如果已经装了新版，也不用急着卸载，只是遇到诡异问题时要先想到这个变量。

2.3 源码目录规划与第三方依赖：第一次 Configure 最怕卡在 IPPICV

目录规划我一般遵循三条：全部英文路径、不含空格、build 目录与源码目录分离。推荐结构是这样：

D:\src\opencv-3.2.0 主仓库源码 D:\src\opencv_contrib-3.2.0 contrib 源码 D:\build-opencv320 编译中间产物，可随时删除重来 D:\opencv320-install 最终安装产物，相当于一个自带的 OpenCV 目录

把 build 和 install 分开放，是因为编译过程中产生的冗余文件非常多，万一 cmake 配置乱了，删 build 重来不影响源码和最终产物。源码目录里有中文或者空格，CMake 在处理 contrib 路径拼接时偶尔会翻车，报错信息还特别难懂，所以一开始就避开。

第一次运行 Configure 时，OpenCV 3.2.0 会尝试下载 IPPICV 和 FFMPEG 这类第三方二进制。如果网络环境一般，configure 会长时间停在 downloading 状态，看着像死机。解决这个问题的常见做法是：先临时把 WITH_IPP 和 WITH_FFMPEG 关掉，让整个工程先编出来，后面确实需要视频读取或性能优化时，再单独补开这两个选项重新编。对于桌面视觉应用，关掉它们的影响可以忽略不计，这是很多老手默认的编译策略。

3. CMake 配置 opencv_contrib：从默认选项到可控的编译范围

3.1 先关掉测试与示例：BUILD_TESTS、BUILD_PERF_TESTS、BUILD_EXAMPLES 三开关

CMake 配置 OpenCV 时，默认会把测试、性能测试和示例代码一起加进工程。这三个选项对日常使用没有任何收益，却会显著拉长编译时间，并让 ALL_BUILD 项目数量暴增。configure 完成后，VS 里会出现几百个项目，绝大部分是测试和示例，新手很容易在茫茫项目列表里迷失。

我一般会在第一次 Configure 后、Generate 之前，把这三项设为 OFF。如果用的是 cmake-gui，在变量列表里搜索 BUILD_TESTS、BUILD_PERF_TESTS、BUILD_EXAMPLES，取消勾选。如果习惯命令行，可以像下面这样一次性填好：

cd D:\build-opencv320 cmake -G "Visual Studio 14 2015 Win64" ` -DCMAKE_INSTALL_PREFIX=D:\opencv320-install ` -DOPENCV_EXTRA_MODULES_PATH=D:\src\opencv_contrib-3.2.0\modules ` -DBUILD_TESTS=OFF ` -DBUILD_PERF_TESTS=OFF ` -DBUILD_EXAMPLES=OFF ` -DBUILD_opencv_world=ON ` D:\src\opencv-3.2.0

这个命令行相当于把 cmake-gui 里的关键变量一次性给全。-G指定生成器；CMAKE_INSTALL_PREFIX决定最终安装位置；OPENCV_EXTRA_MODULES_PATH是最关键的变量，它指向 contrib 的 modules 目录；BUILD_opencv_world决定要不要把所有主模块合并成一个 world 库。最后那个参数是源码根目录，它告诉 CMake 去哪里读主仓库的 CMakeLists.txt。

关于BUILD_opencv_world，这里有一个新手最容易误解的地方：world 库只合并主仓库的模块，contrib 模块不会并进去，仍然以独立 dll 形式输出。也就是说，勾选 world 之后，bin 目录里除了 opencv_world320.dll，还会看到 opencv_xfeatures2d320.dll、opencv_aruco320.dll 这类独立文件，这是正常现象。老工程如果习惯只链接一个 opencv_world320.lib，那么使用 SIFT 时还需要手动追加一条 opencv_xfeatures2d320.lib，这个后面链接配置时会具体讲。

3.2 OPENCV_EXTRA_MODULES_PATH 填到 modules 层：路径差一层，贡献全白给

这个变量是整条链路里最容易出错的地方，几乎所有第一次自己编 contrib 的人都会在这里多踩一脚。OPENCV_EXTRA_MODULES_PATH 的值必须填到 contrib 仓库的 modules 目录这一层，不是 contrib 根目录，也不是 modules 下面的某个子模块。

什么意思呢，假设你的目录是D:\src\opencv_contrib-3.2.0，正确的填法是D:\src\opencv_contrib-3.2.0\modules。如果你填成D:\src\opencv_contrib-3.2.0，CMake 不会直接报错，它会安静地扫描这个目录下的子目录，发现没有可用的模块，然后把 configure 输出里的 Extra modules 一行显示为空。你如果没留意这行日志，继续 Generate、打开 VS、编译，一切顺利，最后才发现 SIFT 头文件根本没有。

判别方法很简单，configure 完成后做两件事：第一，看输出窗口里有没有列出 aruco、xfeatures2d 这些模块名；第二，看 CMake 变量列表里 OPENCV_EXTRA_MODULES_PATH 旁边显示的是不是 NOTFOUND。如果路径填错，CMake 会把这个变量标记为 NOTFOUND，但不会阻止 Configure 继续，所以一定要主动检查。

还有一种情况是路径里带了中文或空格，CMake 在拼接 contrib 子目录路径时会产生乱码，同样会导致模块列表为空。遇到这种问题，最快的处理方式是先把源码挪到纯英文路径，然后删除 build 目录里的 CMakeCache.txt 重新 Configure。不要试着在原来的 build 目录里反复改路径，CMakeCache 里的旧变量残留会让你越改越乱，这是血的教训。

3.3 World 库、INSTALL 前缀与 NONFREE 开关：影响 dll 列表的三个决定

在点 Generate 之前，还有三个决定会影响最终的 dll 列表，建议一次性想清楚。

第一个是 world 库的选择。勾选 BUILD_opencv_world=ON 以后，install 目录的 lib 下只有 opencv_world320.lib 和 opencv_world320d.lib 两个主库文件，链接配置简单；不勾的话，lib 目录下会有几十个模块单独的 lib 文件，每个模块对应一个。老工程如果之前就是链接 opencv_world320.lib，那勾上 world 能让你少改很多工程配置。我自己通常勾上，因为维护成本低，坏处是改任意一个模块都要重编整个 world 库，增量编译变得不那么“增量”。

第二个是 CMAKE_INSTALL_PREFIX。默认值是 C:/Program Files/OpenCV，这个路径带空格，VS 的链接器处理起来虽然没太大问题，但有些脚本和批处理文件会在路径拼接上翻车。我一般改成D:\opencv320-install这种短路径。注意 CMAKE_BUILD_TYPE 这个变量在 VS 生成器下不用刻意设置，因为 VS 的 Debug 和 Release 配置是编译时通过配置管理器切换的，不是 CMake 时决定的，很多人在这里纠结半天其实没必要。

第三个是 OPENCV_ENABLE_NONFREE。在 3.2.0 时代，SIFT、SURF 这类算法受专利影响，默认不启用。在 CMake 变量列表里找到 OPENCV_ENABLE_NONFREE 并勾上，再变回 Generate。不勾这个选项，即使 xfeatures2d 模块编出来，运行时也可能会输出算法受专利保护的提示，甚至直接拒绝计算。这个开关只影响少数几个算法，和 contrib 整体无关，但老工程里用到特征匹配的场景，十个里有八个绕不开它。

4. VS2015 下编译与安装：ALL_BUILD、INSTALL 与三件套配置

4.1 生成 OpenCV.sln 后先切 Release/x64，再决定并行编译线程

Generate 完成之后，build 目录下会出现 OpenCV.sln。用 VS2015 打开它，第一件事不是点生成，而是打开“生成”菜单里的“配置管理器”，把活动解决方案配置切到 Release，活动解决方案平台切到 x64。这里有个常见的翻车点：默认情况下解决方案平台是 Win32，如果你在上面已经用 Win64 生成器生成过工程，这里应该能看到 x64 选项，选中它并点击“生成”。

切好之后，右键 ALL_BUILD 项目，选择“重新生成”。在 VS 里直接点的操作没什么技术含量，但并行线程数值得说一说。OpenCV 3.2.0 全量编译非常吃内存，我见过一台 8GB 内存的机器，开着默认并行度去编，编译到一半内存占满，整个 VS 进程和编译器进程一起被杀掉，build 目录里留下一堆不完整的 .obj 文件。

如果你的机器内存是 8GB，建议控制一下并行度。VS 的“选项-项目和解决方案-生成并运行”里可以设置最大并行项目数，更直接的方式是用命令行控制。下面这条 MSBuild 命令等价于 VS 里的重新生成，只是把并行项目数限制为 4：

& "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" ` D:\build-opencv320\OpenCV.sln ` /m:4 ` /p:Configuration=Release ` /p:Platform=x64 ` /t:Build ` /v:m

/m:4是并行编译的项目数，内存 16GB 以下都建议用这个值，机器好可以改成/m:8。/t:Build表示构建，等价于 VS 里的“生成”；如果改成/t:Rebuild就是“重新生成”，会先清理再编译。/v:m是最小输出，只显示错误和关键信息，编译输出不会刷屏。命令行方式的好处是，编译中途挂了你能看到完整的错误上下文，VS 的错误列表窗口在并行编译下经常会丢行。

编译时长方面，常规配置下四核 CPU 的机器大概要 20 到 40 分钟，新机器 SSD 加八核会快很多。中间过程看起来像“卡住”其实很大概率在编某个大模块，不要因为一两分钟没有输出就手动终止，建议看任务管理器的 CPU 占用率来判断是否还活着。

4.2 输出窗口里两条高频错误：MSB8020 与 C4996 各代表什么

编译过程中出现错误是正常的，关键是看错误属于哪一类。新手容易做的事是盯着错误列表窗口里最后一条红色信息，然后重新生成，再盯着最后一条，循环往复。实际上并行编译时，后面的错误往往是前面某个错误连锁导致的，要看的是“输出”窗口里第一条 E 开头的错误，而不是最后一条。

第一条高频错误是 MSB8020，提示找不到 Visual Studio 2015 的 v140 工具集。这个错误的本质是你机器上装了 VS2017 或 VS2019，但没装 v140 生成工具，或者只装了 VS2015 的某个负载。解决办法是去 VS 安装器里勾选“MSVC v140 - VS 2015 C++ 生成工具”并安装。不要试图把工程平台工具集改成 v141 来绕过，那会让编译结果和后续老工程链接时的运行时不匹配，挖更大的坑。

第二条高频错误是 C4996。OpenCV 3.2.0 的源码里用了一些被 VS2015 标记为不安全的 C 函数，比如fopen、sprintf之类，编译器默认会报 C4996 警告。如果你在 CMake 配置时把警告视为错误，或者 VS 里设置了“警告视为错误”，这些警告会直接中断编译。处理办法很简单，在 CMake 的 C++ 编译选项里加入_CRT_SECURE_NO_WARNINGS这个预处理器定义，或者干脆不要开启警告视为错误。C4996 本身不影响产出的库，老手遇到它通常直接忽略，前提是它确实以 warning 形式出现而不是 error。

4.3 跑 INSTALL 并配置 PATH：把产物收敛成干净的三件套

ALL_BUILD 编译成功不等于工程可用，还需要执行 INSTALL 项目，把散落在 build 目录各个角落的 dll、lib、头文件集中到 CMAKE_INSTALL_PREFIX 指定的目录。在 VS 里右键 INSTALL 项目并生成即可。命令行也一样：

& "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" ` D:\build-opencv320\OpenCV.sln ` /p:Configuration=Release ` /p:Platform=x64 ` /t:INSTALL ` /v:m

INSTALL 完成之后，D:\opencv320-install 下会形成下面这个结构，它就是后续开发要用的“三件套”：

D:\opencv320-install\ ├─ include\opencv2\ 头文件目录 ├─ x64\vc14\bin\ dll 目录 │ ├─ opencv_world320.dll │ ├─ opencv_xfeatures2d320.dll │ └─ opencv_version.exe └─ x64\vc14\lib\ lib 目录 ├─ opencv_world320.lib └─ opencv_xfeatures2d320.lib

bin 目录里的 opencv_version.exe 是自带的版本检查工具，命令行运行它，能直接看到编译时启用的模块列表，后面验证模块有没有编进去可以靠它。这个文件是 OpenCV 编译产物的“活档案”，比你自己猜测靠谱得多。

接下来把 bin 目录加进系统 PATH。这一步不做，程序启动时会在运行时找不到 dll。把 D:\opencv320-install\x64\vc14\bin 追加到用户 PATH 环境变量即可。下面这条命令会把当前会话的 PATH 拼接进用户 PATH，注意 setx 命令会截断超过 1024 字符的环境变量，如果你的 PATH 已经很长，建议手动到系统属性里编辑，而不是用 setx。

setx PATH "$env:PATH;D:\opencv320-install\x64\vc14\bin"

配好 PATH 后，重新打开终端或重启 VS，让新的环境变量生效。VS 进程如果不重启，它不会重新读取系统环境变量，这是很多人配完 PATH 发现还是找不到 dll 的常见原因。

5. 编译与运行避坑：五个值得写进团队笔记的排查案例

5.1 弹窗提示找不到 opencv_world320.dll：先查位数和 PATH

现象：程序编译通过，双击运行时弹出“由于找不到 opencv_world320.dll，无法继续执行代码”，或者直接闪退。

原因分两种。第一种是 PATH 里根本没加 bin 目录，或者加了但 VS 还在用旧环境没有重启。第二种是位数不匹配，你编译的是 x64 程序，但 PATH 里排在前面的某个目录存在一个 32 位的 opencv_world320.dll，程序加载它会报 0xC000007B，表现同样是闪退或无法启动。

解决思路：先打开命令行，运行echo %PATH%看 bin 目录是否存在；确认存在后，在 exe 同目录下用依赖工具看实际加载的 dll 路径。临时验证可以直接把对应位数的 dll 复制到 exe 目录，这样绕开 PATH 的干扰。如果程序是 x64 的就一定用 x64 的 dll，带入自己编译的 Release 版即可，Debug 程序另说，后面一条专门讲 Debug 与 Release 的区分。

5.2 SIFT 运行时输出专利警告或拒算：OPENCV_ENABLE_NONFREE 要先勾

现象：程序编译链接都没问题，SIFT 特征检测的代码也能调用，但运行时控制台输出一段“此算法已申请专利”的提示，甚至detect()调用直接返回空的关键点列表。

原因：xfeatures2d 模块里 SIFT、SURF 这类算法在 3.2.0 时代默认被 NONFREE 开关拦着，CMake 配置时没勾 OPENCV_ENABLE_NONFREE，算法接口虽然存在，但内部行为被限制。

解决步骤：回到 cmake-gui，勾选 OPENCV_ENABLE_NONFREE，重新 Configure 和 Generate，然后用 VS 打开工程，这次不需要全量重编，只重新生成 INSTALL 项目即可。改这一个开关通常只影响 xfeatures2d 模块，增量编译几分钟就能完成。这也是为什么前面强调 build 目录不要删，删了就要从头再编一次。

5.3 编译到一半内存占满被终止：并行线程数不是越高越好

现象：ALL_BUILD 编译进行到后半段，突然 VS 报一堆 “fatal error C1083” 或者编译器进程直接消失，操作系统提示内存不足。

原因：OpenCV 3.2.0 的 C++ 模板代码在编译时非常吃内存，尤其是 xfeatures2d、calib3d 这些模块，单个源文件编译峰值可能超过 2GB 内存。默认并行度等于 CPU 核心数，16GB 内存的机器开 8 核全编，峰值一上来就崩。

解决：用 4.1 节里给的方式限制并行度，8GB 内存用/m:2，16GB 用/m:4。同时建议把中间产物目录放在 SSD 上，编译时产生的中间文件数量巨大，机械盘会拖慢整体速度，但也别指望 SSD 能解决内存问题。如果预算允许，给构建机加内存是最直接的解。

5.4 CMake 里 contrib 模块全是灰色：EXTRA_MODULES_PATH 的两种错法

现象：cmake-gui 的变量列表里，BUILD_opencv_aruco、BUILD_opencv_xfeatures2d 这些变量全部存在但都是灰色，勾不掉；configure 输出里 Extra modules 一行是空的。

原因两种。一种是路径填错位置，OPENCV_EXTRA_MODULES_PATH 填到了 contrib 根目录，或者填到了某个子模块目录，CMake 没在这个位置扫到模块集合。另一种是路径里有中文字符或空格，CMake 解析路径时出了偏差，导致扫描结果为空。

解决：按 3.2 节检查路径是否落在 modules 这一层，同时确认路径是纯英文。改完路径后，最稳妥的做法是删掉 build 目录里的 CMakeCache.txt，重新 Configure。不要相信在 cmake-gui 里改一次路径再 Configure 就一定能清掉旧的变量残留，我实际遇到过两次旧变量残留导致的诡异行为，删缓存重来是最快路径。

5.5 LNK2019 无法解析 xfeatures2d：链接器还少一条 lib

现象：程序编译无错误，链接时报 LNK2019，cv::xfeatures2d::SIFT::create无法解析的外部符号，整个项目链接失败。

原因：你只链接了 opencv_world320.lib，但 SIFT 的实现在 opencv_xfeatures2d320.lib 里。前面说过 world 库只包含主仓库模块，contrib 模块始终是独立 lib，必须手动追加到链接配置里。

解决：在 VS 项目属性里打开“链接器-输入-附加依赖项”，在 opencv_world320.lib 后面追加一行 opencv_xfeatures2d320.lib。Debug 配置对应的是带 d 后缀的库：opencv_world320d.lib 加 opencv_xfeatures2d320d.lib，Release 配置则用不带 d 的那一对。Debug 与 Release 的库千万不能混用，混用表现出的症状更奇怪——有时能编过，有时运行到某个函数直接崩，这类问题排查起来非常费时间，所以配置属性时一定要分配置处理。

6. 验证与归档：用一段 SIFT 检测代码收尾

6.1 最小验证项目的属性配置与验证代码

编译完成后不要急着写业务代码，先建一个最小的控制台项目，把三件套配置好，确认 contrib 真的可用。VS 项目里配置三处：C/C++ 的附加包含目录填D:\opencv320-install\include；链接器的附加库目录填D:\opencv320-install\x64\vc14\lib；附加依赖项填opencv_world320d.lib;opencv_xfeatures2d320d.lib（Debug 配置）或opencv_world320.lib;opencv_xfeatures2d320.lib（Release 配置）。

// contrib_check.cpp #include <opencv2/opencv.hpp> #include <opencv2/xfeatures2d.hpp> #include <iostream> using namespace cv; using namespace std; int main() { Mat src = imread("D:/test.jpg", IMREAD_COLOR); if (src.empty()) { cerr << "image load failed" << endl; return -1; } // create 的第一个参数是保留的关键点数量上限 Ptr<xfeatures2d::SIFT> sift = xfeatures2d::SIFT::create(500); vector<KeyPoint> kps; sift->detect(src, kps); cout << "sift keypoints: " << kps.size() << endl; return 0; }

这段代码的逻辑很直接：读一张测试图，创建一个 SIFT 检测器，调用detect()提取特征点，打印数量。如果 xfeatures2d 没有正确编译并链接，这行xfeatures2d::SIFT::create会在编译或链接阶段直接失败。正常输出应该是一个大于 0 的数字，比如sift keypoints: 2000之类的，说明 contrib 模块从编译到链接整条链路都是通的。

6.2 把编译产物存成固定版本目录，后续少折腾

验证通过之后，建议做一步收尾工作：把整个 D:\opencv320-install 目录压缩打包，命名成类似opencv320-contrib-vc14-x64-release.zip的文件，放进团队共享的依赖仓库。以后新同事接手项目，或者你换了一台机器，直接解压并配置三件套路径即可，不需要再经历一次 CMake 和全量编译。

build 目录也别急着删。它保留了完整的增量编译状态，后面如果需要补编某个模块、切换 Debug 配置，或者重新勾选 OPENCV_ENABLE_NONFREE，都可以在已有基础上几分钟内完成，不用从头再来。我自己刚开始编译时，习惯编完就把 build 目录删掉“省空间”，结果后来要加一个模块，硬生生又跑了四十分钟全量编译。现在我的习惯是：build 留着，install 目录打包归档，两个都不动，直到确定版本不再需要维护为止。

这套 opencv3.2.0 + vs2015 + opencv_contrib 的编译流程，本质上是把一次性工作变成可复用的资产。版本配对、CMake 路径、NONFREE 开关、链接库追加，这几关只要走过一遍，后面再遇到其他 OpenCV 版本的 contrib 编译，思路完全一致。希望这篇笔记能帮你把编译链路一次走通，少踩几个我当年踩过的坑。

本文还有配套的精品资源，点击获取