pip install opencv-python 之后兴冲冲跑cv2.cuda.getCudaEnabledDeviceCount()返回一个 0——这大概是很多人第一次意识到官方轮子根本不带 CUDA 的时刻。我也是这么过来的。想用 GpuMat、想让 DNN 模块跑在显卡上绕不开用 CMake 从源码把 OpenCV 编一遍同时把 CUDA 后端真正塞进去。这件事说难不难但坑非常密显卡算力和 CUDA 版本对不上、make -j开太大直接 OOM、Windows 上蹦出 MSB6006 cmd.exe 退出代码 3、Linux 上装 CUDA 的 .run 包报gzip: stdin: invalid compressed data每一个都够卡半天。下面这份东西是我自己来回编了七八次、又在几台不同配置的机器上复现之后整理出来的从版本对齐、CMake 参数取舍到报错定位的完整链路尽量把为什么讲清楚而不是丢一堆命令让你照抄。适合已经会写点 C/Python、被预编译包卡住、准备自己动手编一份带 CUDA 的 OpenCV 的人。1. 先搞清楚自编译到底换来了什么1.1 官方预编译包为什么天生不带 CUDAPyPI 上的 opencv-python、opencv-contrib-python本质是把 OpenCV 在 CI 上编好的二进制打包分发。分发的机器不一定有 NVIDIA 显卡构建环境也没法保证 CUDA Toolkit 存在所以这些 wheel 在编译时WITH_CUDA一律是 OFF。你装上之后cv2.cuda这个命名空间虽然还能 import但里面的函数一调用就抛异常或者直接告诉你设备数为 0。同样的道理Linux 上apt install libopencv-dev拿到的包绝大部分发行版仓库里也是不带 CUDA 的 CPU 版本。这跟发行版的构建策略有关——编译带 CUDA 的包会引入对闭源驱动的依赖仓库维护者不愿意背这个包袱。所以只要你需要下面任意一项自编译就变成必选项cv::cuda::GpuMat做图像预处理省掉 host 和 device 之间来回拷贝的开销cv::cuda::resize、cv::cuda::cvtColor、cv::cuda::threshold这类批量算子OPENCV_DNN_CUDAON让 DNN 模块把卷积丢给 cuDNN 跑opencv_contrib 里的模块比如face、xfeatures2d、aruco的部分功能、tracking想链上 TBB、OpenMP、Eigen、Intel IPP 这些加速后端做 CPU 侧的调优反过来说如果你的活儿只是 imread、imwrite、形态学、找轮廓、模板匹配这种量级的 CPU 操作自编译纯粹是给自己找麻烦。编译一次 Linux 上半小时到两小时不等Windows 更久中间还要吃几个 G 内存。算清楚这笔账再动手。1.2 编译 OpenCV 时 nvcc 到底在做什么很多人编译报错时一头雾水是因为不知道 nvcc 拿到一个.cu文件之后干了什么。简单说它会把同一个文件拆成两路一路是 host 代码交给系统的 C 编译器另一路是 device 代码先编成 PTX 这种中间表示再针对你在CUDA_ARCH_BIN里指定的算力编成对应架构的 SASS 机器码。这就是为什么CUDA_ARCH_BIN填错会出问题你只编了 sm_75 的 SASS拿到算力 8.6 的卡上跑要么直接报 no kernel image is available要么退回 JIT 编译 PTX第一次调用慢得让你怀疑人生。OpenCV 的 CUDA 模块文件数量不小每个算力都会实打实增加编译时间和二进制体积所以这不是随便填的。理解了这一步后面很多报错就顺了。比如编译期报某个__device__函数找不到多半是头文件包含顺序或者架构宏的问题比如链接期缺符号那是 host 侧和 device 侧的编译单元没对上。1.3 一次完整的构建要跨过几道关从我自己的流程看一次成功的构建要依次过CMake configure 阶段探测依赖找到 nvcc、cuDNN、各第三方库、generate 阶段生成构建文件、build 阶段真正编每个源文件、install 阶段拷贝产物。四个阶段各有各的报错特征定位的时候先判断卡在哪一步能省掉大量瞎猜。阶段典型报错特征大概率原因configure找不到 CUDA_TOOLKIT_ROOT_DIR、cuDNN 版本不匹配路径没配、版本组合不对generate下载 ippicv/ffmpeg/ade 失败网络问题、镜像失效buildcc1plus 被 killed、MSB6006、nvcc fatal内存不足、编译选项冲突、工具链问题install权限拒绝、文件被占用没 sudo、旧版本没卸干净把这张表记在脑子里后面排查会快很多。2. 开工前的版本账驱动、CUDA、cuDNN、编译器怎么对齐2.1 显卡算力是选 CUDA Toolkit 版本的第一约束先确认自己卡的计算能力compute capability。查法很简单装了驱动之后nvidia-smi看型号然后对照下表显卡系列计算能力GTX 10 系1080 Ti 等6.1RTX 20 系2080 Ti 等7.5Tesla V1007.0A1008.0RTX 30 系3090 等8.6RTX 40 系4090 等8.9H1009.0这张表的意义在于算力 8.9 和 9.0 需要 CUDA 11.8 以上的 Toolkit 才能编出 SASS。你要是在 4090 上装 CUDA 11.6nvcc 根本不认识 sm_89 这个 targetconfigure 阶段就会报 unknown option。反过来老卡配太新的 Toolkit 一般没事因为新版本向后兼容旧架构只是你在CUDA_ARCH_BIN里要显式把你需要的算力列出来。驱动版本也不能忽略。CUDA Toolkit 每个版本都有一个最低驱动要求装 Toolkit 的时候安装程序会检查。如果你用 .run 方式装它可能提示你驱动版本不够要么升级驱动要么加--override强行跳过——但强行跳过之后运行时报错会非常隐晦不建议这么干。2.2 cuDNN 与 CUDA 的绑定关系以及 conda 环境里的版本串味cuDNN 是跟 CUDA 大版本绑的。CUDA 11.x 用 cuDNN 8.x for CUDA 11CUDA 12.x 用 cuDNN 8.9/9.x for CUDA 12。下错了版本--version看是能看但 OpenCV 在 configure 阶段调 cuDNN 的探测程序时会链接失败报一堆undefined reference to cudnnCreate之类的符号缺失。这里有个我自己踩过的坑机器上同时有系统装的 CUDA 和 conda 环境里装的cudatoolkit。which nvcc指向的是 conda 里那份但 CMake 探测到的 CUDA_TOOLKIT_ROOT_DIR 又是系统那份两边的头文件版本不一致编到一半才发现。解决办法是统一要么全用系统的要么在 CMake 里显式指定-DCUDA_TOOLKIT_ROOT_DIR/usr/local/cuda-11.8并且在 configure 之前确认nvcc --version和这个路径下的版本一致。查当前环境版本的几条命令# 驱动与显卡 nvidia-smi # CUDA 编译器版本 nvcc --version cat /usr/local/cuda/version.json 2/dev/null # cuDNN 版本头文件里 grep CUDNN_MAJOR -A 2 /usr/local/cuda/include/cudnn_version.hWindows 上对应的是nvcc --version前提是 PATH 里有和查C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\include\cudnn_version.h。2.3 编译器这关GCC 太新、MSVC 版本太低都会被 nvcc 拦下来nvcc 对宿主编译器版本有白名单。CUDA 11.8 官方支持的 GCC 上限大概在 11CUDA 12.x 往上放宽。你在 Ubuntu 22.04 上默认是 GCC 11配 CUDA 11.8 通常没问题但如果系统是 Ubuntu 24.04默认 GCC 13装 CUDA 11.8 编 .cu 的时候就会看到unsupported GNU version! gcc versions later than 11 are not supported。处理办法有两种我一般用第二种# 方案一装老版本 gcc然后让 nvcc 用它 sudo apt install gcc-11 g-11 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100 # 方案二只让 CUDA 用老编译器主工程仍用系统默认 cmake -DCMAKE_C_COMPILER/usr/bin/gcc-11 \ -DCMAKE_CXX_COMPILER/usr/bin/g-11 \ -DCUDA_HOST_COMPILER/usr/bin/gcc-11 ..Windows 那边则是 Visual Studio 版本的问题。OpenCV 4.x 对 VS 2015/2017 的支持早就弱化了用 VS2019 或 VS2022 最稳。老项目里出现的 MSB6006 报错很多就是新老工具集混用导致的这个后面单独讲。CMake 本身建议 3.18 以上3.22 更舒服因为新版 CMake 对 CUDA 是一等公民支持enable_language(CUDA)那套探测逻辑更靠谱。Ubuntu 自带仓库里的 CMake 版本往往偏低需要自己加 Kitware 的源或者下官方二进制包。3. CMake 配置阶段开关怎么拨参数为什么这么填3.1 一份可以直接照抄的 configure 命令下面这条是我在 Ubuntu CUDA 11.8 OpenCV 4.8.0 上跑通的命令按自己的路径改一下就能用cmake -D CMAKE_BUILD_TYPERELEASE \ -D CMAKE_INSTALL_PREFIX/usr/local \ -D OPENCV_EXTRA_MODULES_PATH../../opencv_contrib-4.8.0/modules \ -D WITH_CUDAON \ -D WITH_CUDNNON \ -D OPENCV_DNN_CUDAON \ -D WITH_CUBLASON \ -D CUDA_FAST_MATHON \ -D ENABLE_FAST_MATHON \ -D CUDA_ARCH_BIN8.6 \ -D OPENCV_GENERATE_PKGCONFIGON \ -D BUILD_opencv_python3ON \ -D BUILD_EXAMPLESOFF \ -D BUILD_TESTSOFF \ -D BUILD_PERF_TESTSOFF \ -D BUILD_DOCSOFF \ -D WITH_IPPON \ -D WITH_TBBON \ ..逐个说下取舍CMAKE_BUILD_TYPERELEASE是必须的Debug 模式下 CUDA 代码编译会慢到离谱而且体积翻好几倍。CUDA_FAST_MATHON会让 nvcc 用精度换速度对图像处理这种容忍误差的场景基本没影响但如果你的算法对浮点结果敏感就得关掉。WITH_CUDNNON和OPENCV_DNN_CUDAON要一起开前者是编 CUDA 后端的基础后者才真正把 DNN 模块接到 cuDNN 上。只开前者的话DNN 还是走 CPU。WITH_CUBLASON在涉及矩阵运算的模块里有用比如某些特征匹配和 DNN 的 fully connected 层不开也不报错就是慢一点。BUILD_TESTS和BUILD_PERF_TESTS一定要关。这两个在带 CUDA 的情况下会编出大量测试可执行文件编译时间翻倍而且其中一部分测试程序本身在某些 CUDA 版本下就编不过白白浪费你排查的时间。OPENCV_GENERATE_PKGCONFIGON在 Linux 上强烈建议开着后面用pkg-config找库的时候省事。OpenCV 4.x 生成的是opencv4.pc。3.2 CUDA_ARCH_BIN 填什么别把时间浪费在编用不上的算力上默认情况下如果你不指定CUDA_ARCH_BINOpenCV 的 CMake 脚本会自动探测当前显卡的算力只编那一个。这其实是最省时间的做法。但如果你编好的库要分发到别的机器上或者你机器上有多张不同代的卡就得手动列出来。格式是逗号分隔比如-D CUDA_ARCH_BIN7.5;8.0;8.6。注意每多一个算力所有 CUDA 相关的 .cu 文件都要额外编一遍时间是线性增长的。我有一次为了兼容填了六个算力结果 i7 的机器上编了将近三个小时最后发现实际只用得上一个。还有一种情况如果你的 CUDA 版本不支持某个算力但你又必须让代码在那张卡上跑可以加-D CUDA_ARCH_PTX8.9让 nvcc 把 PTX 中间码编进去运行时 JIT 成目标架构的 SASS。代价是首次调用会慢几百毫秒到几秒如果这段代码在循环里问题不大只在程序启动时跑一次就有点难受。3.3 那些默认打开、但会让构建时间翻倍的选项OpenCV 的默认配置偏全都要对自编译来说很不友好。几个值得手动关掉的BUILD_JAVAOFF不写 Java 的话直接关省掉 ant 相关的探测和编译BUILD_opencv_worldON如果你只要一两个模块关掉它反而能让你按需挑选模块编译WITH_1394、WITH_GSTREAMER、WITH_V4L只在做视频采集时才需要纯图像处理可以关WITH_OPENCL除非你确定要用 OpenCL 后端否则关掉能省一点关法的核心思路是只编你真正会用到的模块。比如只做图像预处理和 DNN 推理那BUILD_opencv_photo、BUILD_opencv_stitching、BUILD_opencv_videostab这些都可以关掉。模块少了configure 阶段要下的第三方依赖也少了build 阶段的坑自然就少。configure 跑完之后一定要回头看输出的最后那段汇总确认关键项的状态-- NVIDIA CUDA: YES (ver 11.8, CUFFT CUBLAS FAST_MATH) -- NVIDIA GPU arch: 86 -- NVIDIA PTX archs: -- cuDNN: YES (ver 8.7.0) -- OpenCL: YES -- Python 3: YESNVIDIA CUDA是 YES、cuDNN是 YES、NVIDIA GPU arch和你的卡对上这三条满足了再往下走。不然编完才发现 CUDA 根本没进去白等一小时。4. 编译阶段的报错定位链路从 OOM 到 MSB60064.1 先看是不是内存被打爆build 阶段最常见的失败其实不是编译错误是内存不够被系统杀进程。典型表现是编译到某个进度突然中断终端只留一句c: fatal error: Killed signal terminated program cc1plus或者干脆什么都不打印make返回非零。原因是 OpenCV 的 CUDA 模块里有很多复杂模板nvcc 处理这些文件时单个进程的内存占用可以到 1.5~2 GB。你用make -j$(nproc)在 8 核机器上并行跑 8 个 nvcc轻松吃掉 16 GB。排查方法# 看有没有 OOM killer 的记录 dmesg | grep -i killed process | tail -20 # 或者看系统日志 journalctl -k | grep -i oom确认是内存问题之后处理方式按代价排序降并行度make -j4甚至make -j2慢是慢但稳加 swap临时开一个 8~16 GB 的交换文件能顶一阵单独降低 CUDA 模块的并行度先make -j2把opencv_cudev、opencv_core这些模块编完再整体make -j8我自己的习惯是先用make -j4跑一遍反正一次成功比反复重来强。4.2 第三方依赖下载失败卡在中途CMake configure 阶段OpenCV 会去下载几个第三方文件ippicv、ffmpeg 的 prebuilt、ade图计算用、还有 xfeatures2d 里的 boostdesc 和 vgg 描述子文件。这些文件的下载地址在3rdparty/下的.cmake文件里写死国内网络环境下经常超时。表现是 configure 跑到一半停了报CMake Error at cmake/OpenCVDownload.cmake: ... Failed to download。有时候下载成功了但中间其实被劫持成了一个 HTML 错误页文件大小不对到 build 阶段才炸出解压错误。处理办法有两个方向方向一是换镜像比如清华的镜像站或者手动把文件下好放到.cache目录。OpenCV 的下载缓存路径在~/.cache/opencv/Linux和%USERPROFILE%\.cache\opencv\Windows。你把正确的文件按它期望的文件名放进去再重新 configure它检测到文件存在且哈希匹配就会跳过下载。方向二是在 configure 时直接关掉相关模块-D BUILD_opencv_xfeatures2dOFF \ -D WITH_FFMPEGOFF \ -D BUILD_opencv_adeOFF代价是失去对应功能但对主流程没影响。我先用方案二跑通一次完整编译确认整条链路没问题再回头补那些依赖比一开始就跟网络死磕效率高得多。4.3 Windows 上的 MSB6006 cmd.exe 已退出代码为 3这个报错信息本身极其没有信息量它只是说 MSBuild 调用的一条外部命令返回了 3。真正的原因在它上面几行的输出里。在 OpenCV 的 VS 工程里返回码 3 最常见的三个来源第一CUDA 的 custom build step 调用 nvcc 失败了。VS 里每个 .cu 文件是通过一个自定义生成步骤调 nvcc 编的如果 nvcc 路径里有空格或者中文或者CUDA_PATH环境变量没设对这条命令就会失败。第二Python 相关的 post-build 步骤。如果你开了 python 绑定VS 工程里会有一步调用 Python 去处理绑定文件Python 解释器找不到或者模块缺失都会返回非零。第三路径过长。Windows 的路径长度限制是 260 字符OpenCV 的构建目录如果放在深层目录下很容易超限编译过程中某个中间文件写不进去就报这个。定位方法把 MSBuild 的输出详细程度调到 Detailed。命令行版是msbuild OpenCV.sln /p:ConfigurationRelease /v:detailed或者直接在 VS 里 工具 → 选项 → 项目和解决方案 → 生成并运行把 MSBuild 输出详细程度改成详细。然后在输出里搜error MSB6006往上翻能直接看到失败的那条命令和它的真实报错。我遇到过一次实际原因就是源码目录路径里有个中文文件夹名改成全英文路径之后就过了。4.4 .run 安装包报 gzip: stdin: invalid compressed data装 CUDA Toolkit 时如果用.run文件执行的时候报这个说明文件本身不完整。CUDA 的 .run 其实是一个 shell 脚本头 gzip 压缩的 tar 包拼接起来的自解压文件。脚本会跳过前面的头部把后面的部分解压。如果下载过程中断了、或者中间经过了会修改内容的缓存gzip 的校验就过不去。处理方式# 先校验官网页面会给 sha256 或 md5 sha256sum cuda_11.8.0_520.61.05_linux.run # 不匹配就重新下建议用 wget/curl 并开启断点续传 wget -c https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run顺便提一句如果 .run 装到一半提示检测到已有驱动那说明系统里已经装了驱动这时候在安装选项里把 Driver 那一项去掉只装 Toolkit 就行。全勾上很容易把显卡驱动搞坏重启进不了图形界面。5. 编完不算完确认 CUDA 真的生效以及怎么接进自己的工程5.1 三行代码验证 CUDA 模块install 跑完之后先别急着改自己的工程用最小示例验证一下。C 版本#include iostream #include opencv2/core.hpp #include opencv2/core/cuda.hpp int main() { int n cv::cuda::getCudaEnabledDeviceCount(); std::cout CUDA devices: n std::endl; if (n 0) { cv::cuda::printShortCudaDeviceInfo(0); } return 0; }编译g test_cuda.cpp -o test_cuda $(pkg-config --cflags --libs opencv4)如果getCudaEnabledDeviceCount()返回 0别怀疑代码先回头检查 configure 汇总里NVIDIA CUDA那一栏是不是 YES。返回大于 0 但printShortCudaDeviceInfo里显示算力和你的卡不符那说明CUDA_ARCH_BIN填错了得重编。Python 版本验证的时候有个小陷阱cv2.cuda.getCudaEnabledDeviceCount()注意是cv2不是opencv。社区里那个ModuleNotFoundError: No module named opencv的经典报错十有八九是把 import 名字写错了。Python 侧装带 CUDA 的 OpenCV如果你是用自编译的需要把生成的cv2.*.so拷到 site-packages或者在 CMake 里-D PYTHON3_PACKAGES_PATH指到正确路径。用 conda 环境的话还要注意别被 conda 里那个 CPU 版覆盖掉。5.2 在 CMake 工程里链接自编译的 OpenCV自己的工程用 CMake 管理的话最省事的办法是 install 之后用find_package。cmake_minimum_required(VERSION 3.18) project(my_vision) set(CMAKE_CXX_STANDARD 17) find_package(OpenCV REQUIRED) find_package(CUDA REQUIRED) message(STATUS OpenCV version: ${OpenCV_VERSION}) message(STATUS OpenCV CUDA: ${OpenCV_CUDA_VERSION}) add_executable(my_app main.cpp) target_include_directories(my_app PRIVATE ${OpenCV_INCLUDE_DIRS}) target_link_libraries(my_app PRIVATE ${OpenCV_LIBS} ${CUDA_LIBRARIES})要注意的是find_package(OpenCV)找的是OpenCVConfig.cmake如果你的系统里还有 apt 装的旧版本可能会找到那个。定位方法是在find_package后面打印OpenCV_DIR确认指向的是你自己 install 的路径。不放心的话直接在 configure 时加-DOpenCV_DIR/usr/local/lib/cmake/opencv4。Windows 上还有一个容易忽略的点把C:\opencv\build\install\x64\vc16\bin加进系统 PATH否则运行时报找不到opencv_world480.dll。5.3 Windows 工程转到 Linux 编译时的连锁报错把 VS 工程搬到 Linux 上用 CMake 编是另一个高频场景报错往往成串出现。几个固定的坑第一路径分隔符。代码里硬编码的data\\image.jpg在 Linux 上找不到文件要么改成/要么用std::filesystem::path。CMake 里同理\要换成/。第二文件名大小写。Linux 文件系统区分大小写#include opencv2/Opencv.hpp在 Windows 上能过Linux 上直接报找不到头文件。老老实实按真实文件名写。第三Windows 专有 API。__declspec(dllexport)、windows.h、Sleep()、_tmain这些在 Linux 上都不存在。导出符号改用__attribute__((visibility(default)))或者在 CMake 里统一用generate_export_headerSleep换成std::this_thread::sleep_for。第四字符编码。MSVC 默认源码是 GBK 或带 BOM 的 UTF-8GCC 默认 UTF-8 无 BOM。源文件里有中文注释或字符串的时候可能出现乱码或者编译警告。统一转成 UTF-8 无 BOM。第五第三方库。Windows 上用的.lib静态库在 Linux 上没法用得找对应的源码重新编或者用包管理器装.so。这一步经常是最耗时间的。6. 几个总被误判成编译错误的环境问题6.1 cmake 命令找不到先查 PATH 和终端会话PowerShell 里敲cmake报无法将cmake项识别为 cmdlet、函数、脚本文件或可运行程序的名称这是环境变量的问题跟编译本身没半点关系。排查顺序# 看 cmake 在不在 PATH 里 where.exe cmake $env:Path -split ; | Select-String -Pattern CMake # 临时加进当前会话 $env:Path ;C:\Program Files\CMake\bin装完 CMake 之后必须重开终端因为环境变量的更新不会自动同步到已经开着的窗口。VS Code 里的集成终端也一样要整个重启。这个坑我踩过至少三次每次都是先怀疑安装包有问题折腾半天才发现是没重启终端。Linux 上类似用官方.sh装的 CMake 默认装到/usr/local/bin这个路径一般已经在 PATH 里。如果是手动解压的二进制包得自己export PATH$PATH:/opt/cmake/bin并且写进.bashrc。6.2 相机调用、人脸识别这些功能和你编的模块有没有关系经常有人问我编译带 CUDA 的 OpenCV是不是调用相机也能加速答案是不能。cv::VideoCapture的底层是 V4L2Linux、MSMF 或 DirectShowWindows这些系统后端帧的读取、解码走的是 CPU 路径跟 CUDA 一点关系没有。你要加速的是拿到帧之后的处理环节也就是把cv::Mat上传成cv::GpuMat在显存里做完 resize、颜色转换、推理再拿回来。所以正确的心态是相机读取保持原样把后面的计算搬到 GPU 上。至于人脸识别OpenCV 自带的cv::FaceDetectorYNYuNet和cv::FaceRecognizerSF这类接口本身是 CPU 也能跑的CUDA 加速主要体现在神经网络推理那一层。如果你开了OPENCV_DNN_CUDAON并且用net.setPreferableBackend(cv::dnn::DNN_BACKEND_CUDA)加上setPreferableTarget(cv::dnn::DNN_TARGET_CUDA)那推理就会走 cuDNN。否则默认还是 CPU。GrabCut 这类算法在imgproc模块里是纯 CPU 实现OpenCV 没有提供 CUDA 版本想加速得自己写。Android 上另外有一套 OpenCV 的预编译包跟本文这套桌面端的编译流程不是一回事。6.3 卸载和重装别让旧版本干扰新编译最后说一个很多人忽略的点。如果你之前用 apt 或者别的方式装过 OpenCV新编的库 install 之后pkg-config --modversion opencv4拿到的可能还是旧版本因为/usr/lib/x86_64-linux-gnu/pkgconfig/下的.pc文件优先级和/usr/local/lib/pkgconfig/不一样。排查办法是先看pkg-config --variableprefix opencv4指向哪确认是不是/usr/local。不是的话要么在PKG_CONFIG_PATH里把/usr/local/lib/pkgconfig放到前面要么把系统那份卸掉。卸载自编译版本的时候因为make install不会记录文件清单最干净的方式其实是当初装之前用checkinstall生成一个 deb 包之后用包管理器卸载。如果已经直接 install 了至少要把/usr/local/lib/libopencv_*、/usr/local/include/opencv4/、/usr/local/lib/cmake/opencv4/、/usr/local/lib/pkgconfig/opencv4.pc这几处清掉再重新编。残留的旧.so会在链接时被优先找到导致你明明改了 CMake 参数编出来的程序行为还是旧的。我个人踩下来最省事的做法是在虚拟机或者容器里做一次全新编译把整个 configure build install 的命令序列记成一个脚本存起来。以后换机器、换 CUDA 版本改几个变量重跑一遍就行不用再从头摸一遍坑。真正的坑其实就那么几个把它们写进脚本注释里比任何笔记都管用。