用过Ubuntu 18.04做视觉开发的朋友，估计都经历过头疼时刻：系统里跑着ROS Melodic，自带OpenCV 3.2，结果为了用新算法手痒编译了个OpenCV 4.5，编译器立刻给你上演“头文件找不到”“库版本冲突”“ROS节点莫名崩溃”的连续剧。这问题几乎每个搞机器人、无人车、视觉SLAM的开发者都撞上过，区别只是踩坑深浅。我花了不少时间把C++和Python两套环境的搭建方式、以及和ROS和平共处的方案彻底摸了一遍，今天把能直接照着抄的完整过程整理出来，希望能帮你少走些弯路。
这篇文章涵盖的内容包括：Ubuntu 18.04下OpenCV源码编译的完整步骤（C++方向）、Python环境的两种推荐搭配方式（pip与conda）、以及四种实测有效的OpenCV与ROS冲突解决方案。无论你是刚开始搭环境的新手，还是已经被编译错误折磨到抓狂的进阶玩家，这篇文章里的命令、参数和排查思路都能直接拿来用。
1. 为什么Ubuntu 18.04上的OpenCV总和ROS打架：冲突根源与方案选型
1.1 冲突根源：一套系统里存在两套OpenCV
在动手之前，先搞清楚问题本质。Ubuntu 18.04搭配的ROS Melodic发行版，骨子里依赖的是OpenCV 3.2.0。这个版本不光被ROS核心模块使用，还被大量ROS生态包依赖，特别是图像处理里最常用的cv_bridge功能包，它专门负责在ROS的图像消息（sensor_msgs/Image）和OpenCV的Mat对象之间做转换。
问题来了：当你为了使用新版算法，手动从源码编译安装了OpenCV 4.x之后，系统里就同时存在了两套OpenCV：
- 一套是apt安装的OpenCV 3.2，头文件在
/usr/include/opencv和/usr/include/opencv2，库文件在/usr/lib/x86_64-linux-gnu/。 - 另一套是源码编译的OpenCV 4.x，头文件在
/usr/local/include/opencv4，库文件在/usr/local/lib。
两套库同时存在本身没有致命问题，致命的是它们的头文件和动态库名称高度重叠。几乎所有源码编译的OpenCV 4.x都会生成libopencv_core.so这样的文件，而apt版OpenCV 3.2同样也生成libopencv_core.so。你的工程一旦同时把/usr/include和/usr/local/include都加入到搜索路径，编译器就会随机抽取头文件版本，而链接器也不知道该优先链接哪个库文件。轻则编译报错，重则程序运行时加载到不匹配的动态库版本，直接崩溃，连错误信息都来不及给。
1.2 方案选型：三条路线怎么选
搞清楚冲突原因之后，我们再谈方案。针对不同的使用场景，我整理了三套思路，你可以根据自己的实际需求选：
方案A：纯apt安装，一条命令搞定。对所有要求不高的开发场景，尤其是以ROS开发为主、OpenCV只是辅助的场景，直接sudo apt install libopencv-dev。这套方法装的OpenCV 3.2和ROS完全同源，不会有版本摩擦。缺点是版本太老，很多新算法（如部分DNN模块、新的特征检测算子）用不了。
方案B：源码编译OpenCV 4.x，走/usr/local前缀，主打C++开发。这条路适合那些需要新版OpenCV接口的C++项目，比如自己写视觉算法、想用SIFT新实现、跑YOLO的DNN推断等。这条路的难点就是和ROS共存，需要额外的头文件路径和链接管理。本文第2节和第4节重点讲这条路线。
方案C：Python环境走conda或pip虚拟环境隔离，主打Python开发。Python方向我强烈建议把OpenCV装进独立环境里，不要直接装在系统Python里。因为Ubuntu 18.04系统自带的Python 3.6被ROS深度绑定，你一旦用pip强制升级或降级某些包，很容易把系统python的依赖关系搞坏，严重时ROS节点启动都困难。第3节会详细说明具体操作。
我的实际建议是组合拳：C++项目走源码编译的4.x，Python项目走conda虚拟环境，ROS项目保持apt的3.2不动。三者通过路径隔离和环境变量隔离互不干扰。这套组合我用了很长时间，稳定可靠。
2. C++环境搭建：源码编译OpenCV 4.x完整流程
2.1 安装前的依赖准备：一个都不能少
源码编译OpenCV最痛苦的部分不是编译本身，而是编译前的依赖准备。依赖没装齐，编译到一半报错，又得从头再来，非常搞心态。我在Ubuntu 18.04上反复折腾过几次之后，总结出了下面这套依赖安装命令，基本覆盖全部需求：
sudo apt update sudo apt install -y build-essential cmake git pkg-config sudo apt install -y libjpeg8-dev libtiff5-dev libpng-dev sudo apt install -y libavcodec-dev libavformat-dev libswscale-dev libv4l-dev sudo apt install -y libxvidcore-dev libx264-dev sudo apt install -y libgtk-3-dev sudo apt install -y libatlas-base-dev gfortran sudo apt install -y python3-dev python3-numpy逐行解释一下关键包的作用：build-essential提供gcc、g++等基础编译器；cmake是OpenCV用的构建工具；libgtk-3-dev负责提供GUI窗口支持，少了它即使编译成功，cv::imshow也无法显示窗口；libavcodec-dev等一组库是视频编解码的核心依赖，少了它们VideoCapture读取视频文件会失败；python3-dev和python3-numpy则是编译Python绑定时必需的。
这里特别提醒一句：libjpeg8-dev这个包名在Ubuntu 18.04里存在，但实际系统可能已经通过libjpeg-turbo8-dev提供相同功能，如果你在安装时提示找不到包，就换成libjpeg-turbo8-dev，不影响OpenCV编译。这种依赖命名差异在18.04上很常见，不用慌。
2.2 下载源码与CMake配置：参数就是命运
依赖准备好之后，接下来是获取源码。用git方式拉取比较省事，还能方便切换版本：
cd ~ git clone https://github.com/opencv/opencv.git git clone https://github.com/opencv/opencv_contrib.git cd opencv git checkout 4.5.5 cd ../opencv_contrib git checkout 4.5.5这里选择4.5.5版本是出于稳定性考虑，4.x系列中这个版本比较成熟，且和Ubuntu 18.04默认的GCC 7.5.0兼容良好。主仓库和contrib扩展模块仓库必须切到同一个版本标签，否则编译时会出现模块接口对不上的问题。
源码就位后，创建build目录并运行cmake：
cd ~/opencv mkdir build && cd build cmake -D CMAKE_BUILD_TYPE=RELEASE \ -D CMAKE_INSTALL_PREFIX=/usr/local \ -D OPENCV_EXTRA_MODULES_PATH=~/opencv_contrib/modules \ -D WITH_TBB=ON \ -D WITH_OPENMP=ON \ -D WITH_GTK=ON \ -D BUILD_opencv_python3=ON \ -D PYTHON3_EXECUTABLE=$(which python3) \ -D BUILD_EXAMPLES=OFF \ -D INSTALL_PYTHON_EXAMPLES=OFF \ -D BUILD_TESTS=OFF \ ..几个关键参数解读一下。CMAKE_INSTALL_PREFIX=/usr/local是源码编译软件的标准安装位置，跟前述的apt版OpenCV（安装到/usr）区分开，这是解决冲突的第一步。OPENCV_EXTRA_MODULES_PATH指向contrib仓库的模块目录，想要SIFT、SURF这些经典特征算法就必须指定，否则OpenCV 4.x主仓库里默认不带它们。WITH_TBB和WITH_OPENMP是并行计算支持，对图像处理性能有明显提升，建议打开。
BUILD_opencv_python3=ON这个参数很多人容易忽略。不加的话，编译产物里就没有Python3的绑定模块。但注意，即便开了这个开关，由于系统里同时存在Python 3.6（系统）和可能的conda Python（如3.9/3.10），cmake也可能选择了错误的Python版本。保险的做法是显式指定PYTHON3_EXECUTABLE，告诉cmake你到底想给哪个Python版本生成绑定。
2.3 编译、安装与C++验证：亲眼看到结果才放心
cmake配置完毕没有报错的话，接下来就是见证CPU风扇狂转的时刻：
make -j$(nproc) sudo make install sudo ldconfigmake -j$(nproc)会调用所有CPU核心参与编译，速度可以快好几倍。但有个特殊情况：如果机器内存只有8G，十几核同时编译很容易把内存耗尽导致OOM，进程直接被杀。我建议内存紧张的同学用make -j4，慢一点但至少不会中途挂掉。编译过程通常会持续15到30分钟，出去泡杯茶正好。
安装完成后，老规矩，写个最简单的C++程序验证环境是否可用。我习惯建一个test_opencv.cpp：
#include <opencv2/opencv.hpp> #include <iostream> int main() { cv::Mat img = cv::Mat::zeros(300, 300, CV_8UC3); cv::putText(img, "OpenCV OK", cv::Point(50, 150), cv::FONT_HERSHEY_SIMPLEX, 1.0, cv::Scalar(0, 255, 0), 2); cv::imwrite("test_result.jpg", img); std::cout << "OpenCV version: " << CV_VERSION << std::endl; return 0; }编译命令：
g++ test_opencv.cpp -o test_opencv `pkg-config --cflags --libs opencv4` ./test_opencv如果屏幕上打印出OpenCV 4.5.5，并且当前目录生成了test_result.jpg，说明C++环境已经可用。这里有个分水岭：打印的版本号如果是4.5.5，说明链接的是源码编译的新版；如果打印3.2.0，说明pkg-config还在指向apt版OpenCV路径，需要检查PKG_CONFIG_PATH环境变量。这个问题我们会在第4节的冲突解决方案里详细处理。
3. Python环境：用对隔离，别让ROS陪你一起翻车
3.1 系统pip安装的隐患：你能装，但我不推荐
Python调用OpenCV最方便的方式当然是pip install opencv-python，一条命令就完成了。如果你只是在本机做一些独立的图像处理实验，跟ROS没有半毛钱关系，那这么装完全没问题，省心省力。
但问题就出在“系统pip”这三个字上。Ubuntu 18.04的pip3 install默认装到/usr/lib/python3/dist-packages，这个目录是ROS Python依赖的驻地。执行pip3 install opencv-python时，pip会顺手检查依赖，可能触发numpy等核心库的升级。一旦numpy从系统要求的版本被升到另一个版本，ROS底层很多依赖numpy的功能包直接罢工。我见过最惨的一次，仅仅装了个opencv-python，同事的roslaunch就再也起不来了，报错全是numpy ABI不匹配。
所以我的建议简单粗暴：不乱动系统环境，给Python开发单独开一间“房”。
3.2 conda虚拟环境：Python开发的首选归宿
我用的Python环境隔离工具是Miniconda，比Anaconda轻量，装起来也快。下载安装脚本后直接执行：
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装完成后，创建一个独立的虚拟环境：
conda create -n cv4 python=3.8 -y conda activate cv4注意这里选Python 3.8而不是系统默认的3.6，目的就是彻底避开系统Python的干扰。接下来在这个环境里安装OpenCV：
conda install opencv -c conda-forge -y或者用pip安装（两种方式任选其一）：
pip install opencv-python opencv-contrib-python装完之后验证一下版本：
python -c "import cv2; print(cv2.__version__)"正常情况下会打印4.x版本号。这里有个非常关键的小验证步骤：检查cv2模块实际导入路径。
python -c "import cv2; print(cv2.__file__)"拿到这个路径后确认它位于conda环境目录下，而不是/usr/lib/python3/dist-packages。如果输出路径仍然指向系统目录，说明conda环境没有彻底隔离，需要检查PYTHONPATH环境变量里是不是有人手动加了系统路径。
3.3 Python与ROS共存时的额外注意事项
即使你用了conda虚拟环境，和ROS共存时还会遇到一个意想不到的问题：import cv2倒是正常，但如果某个程序同时导入了ROS的cv_bridge，两边会打起来。
原因是cv_bridge是ROS里用系统Python编译的，它内部链接的系统OpenCV 3.2，而你在conda环境里用的是OpenCV 4.x。Python本身的cv2模块和cv_bridge的C++底层库同时存在时，由于它们引用的OpenCV符号版本不一致，程序跑起来就会时不时崩溃。
规避的方法是：不要在同一个Python进程里混用conda环境中的cv2和ROS的cv_bridge。凡是涉及ROS消息和图像转换的功能，应该写成独立的ROS节点（用系统Python执行），而纯算法部分走conda环境。如果你确实需要在一个脚本里同时使用ROS和OpenCV的新版本接口，那就要考虑下一种兼容方案：把ROS的cv_bridge也换成OpenCV 4.x重新编译。这个方法操作比较重，但对某些特定项目确实是最优解，我会在第4节给出思路。
4. OpenCV与ROS冲突的终极解决方案：四招实测可用
4.1 冲突现象速查：先判断你的问题属于哪一类
我在整理解决方案之前，先把常见的冲突现象列出来，方便你对号入座：
| 现象 | 触发场景 | 根因 |
|---|---|---|
编译时报错：找不到opencv2/opencv.hpp | 自己的C++工程 | 头文件路径没包含OpenCV 4.x目录 |
| 编译时报错：函数在cv::命名空间中未定义 | 自己的C++工程 | 头文件用的是3.2，但链接的是4.x，或反之 |
| 编译ROS功能包时突然报OpenCV相关错误 | ROS catkin_make | ROS默认的3.2路径和自定义4.x路径冲突 |
程序编译通过但运行时崩溃，提示libopencv_core.so.3.2找不到 | 运行自己的程序 | 程序链接时指向了3.2库，但3.2库文件被4.x覆盖 |
Python里import cv2后调用图像显示，秒退 | Python环境 | Python加载了错误版本的cv2.so |
| ROS节点启动后，图像话题回传全是黑屏 | ROS+rviz | cv_bridge链接的OpenCV版本与其他组件不一致 |
对号入座之后，下面四招按需使用。
4.2 策略一：头文件与库的路径分离管理
核心思路：让系统同时存在两套OpenCV，但通过路径优先级让不同的工程各取所需。
源码编译的OpenCV 4.x默认装在/usr/local，apt版OpenCV 3.2装在/usr。这两个目录在C/C++编译器的默认搜索路径里是有先后顺序的：/usr/local/include优先于/usr/include，/usr/local/lib优先于/usr/lib。也就是说，如果你只是普通编译一个不带ROS的独立C++程序，编译器天然会优先找到/usr/local里的OpenCV 4.x，这其实是安全的。
问题大多出在ROS的catkin编译环境。catkin会显式添加大量-I/opt/ros/melodic/include这样的参数到编译命令里，而ROS的include目录恰好包含OpenCV 3.2的头文件路径。最终编译命令里/usr/local/include/opencv4和/opt/ros/melodic/include/opencv-3.2.0都会被搜索，头文件版本之战就此爆发。
解决思路是：在编译ROS功能包时，不要模糊搜索头文件，而是让cmake显式地只找其中一个版本。在你自己的CMakeLists.txt里指定OpenCV的路径：
set(OpenCV_DIR "/usr/local/lib/cmake/opencv4") find_package(OpenCV 4 REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS}) target_link_libraries(your_target ${OpenCV_LIBS})OpenCV_DIR指向源码编译安装时生成的cmake配置文件目录，find_package就能精准找到OpenCV 4.x的配置。这样即使系统里还躺着3.2，你的工程也不会混淆。
4.3 策略二：CMake工程显式指定OpenCV版本
这条策略是针对自己的C++工程，而非ROS功能包。很多人在自己的项目里写find_package(OpenCV REQUIRED)，这样cmake会按照默认路径搜索，在同时存在两套库的时候，找到哪个全看搜索顺序的运气。
更好的写法是主动指定版本和路径，把不确定性排除：
set(OpenCV_DIR "/usr/local/lib/cmake/opencv4") find_package(OpenCV 4.5 REQUIRED) message(STATUS "OpenCV_INCLUDE_DIRS = ${OpenCV_INCLUDE_DIRS}") message(STATUS "OpenCV_LIBS = ${OpenCV_LIBS}")find_package(OpenCV 4.5 REQUIRED)会强制要求找到4.5这个版本，如果搜到3.2，cmake会直接报错，而不是偷偷用错误版本继续往下走。message语句用于打印实际找到的路径和库，方便你确认cmake到底选中了哪套OpenCV。建议每次配置完编译前都看一眼这两行输出信息，能省下大量排查时间。
4.4 策略三：ROS端的cv_bridge版本对齐
如果你的项目必须同时用到ROS的消息系统和新版OpenCV（比如你在写一个订阅图像话题，又要用DNN模块做推理），前面两个策略就不够了，问题出在ROS的cv_bridge还没跟新版OpenCV对齐。
标准的cv_bridge依赖系统OpenCV 3.2。如果要让ROS生态整体拥抱OpenCV 4.x，就需要重新编译cv_bridge。流程不复杂但要注意细节。先找到cv_bridge的源码（在ROS官方仓库可以拉取，对应melodic分支），然后修改它的CMakeLists.txt：
set(OpenCV_DIR "/usr/local/lib/cmake/opencv4") find_package(OpenCV 4 REQUIRED)然后重新编译整个工作空间。这个过程相当于把ROS的视觉依赖基础从3.2升级到4.x。缺点是可能有一批旧版本的功能包接口不兼容，需要你逐个排查。优点是只要编译通过，整个ROSN生态就统一在OpenCV 4.x下了，后续开发再也不用关心版本错位问题。
这条路只建议对ROS生态控制力比较强、功能包数量有限的开发者尝试。如果工作空间里有大量第三方ROS包，我不建议升级cv_bridge，风险太大。我就是在这上面吃了大亏之后，才转向了第4.5节的方案。
4.5 策略四：物理隔离，互不相干
这是我个人最终采用的方案，也是我认为最稳妥的方案：让ROS系统的OpenCV和自定义OpenCV彻底物理隔离，互不干涉。
具体操作分三层：
第一层，ROS系统包保持apt版OpenCV 3.2不动，不卸载、不升级、不覆盖。确保/opt/ros/melodic路径下的所有库都保持原样。
第二层，自定义C++算法程序的CMakeLists.txt里，强制只找OpenCV 4.x：
set(OpenCV_DIR "/usr/local/lib/cmake/opencv4") find_package(OpenCV 4 REQUIRED)禁止把/opt/ros/melodic/include加入到自定义算法的include path里。
第三层，Python端统一走conda虚拟环境，路径由PYTHONPATH严格指定。在~/.bashrc里加一行：
# 仅在需要时激活conda环境，不要全局设置PYTHONPATH conda activate cv4同时，不要设置全局PYTHONPATH=/usr/local/lib/python3.6/site-packages，否则又会把源码编译时期生成的cv2.so引入系统Python环境，造成混乱。如果你发现系统Python和conda环境的OpenCV发生了交叉，用：
type -a python python -c "import sys; print(sys.path)"检查启动顺序，确认当前shell里用的是哪个python，再对症调整~/.bashrc。
这套三层隔离方案执行下来，我这边的开发环境和ROS环境已经稳定共处了很长时间，基本没有再出现莫名其妙的版本打架问题。
5. 常见问题与排查技巧实录
5.1 高频报错排查速查表
把上面所有方案归结完后，我整理了实际运行中最常遇到的报错和对应解法，做成一张速查表方便你直接检索。
| 报错或现象 | 可能原因 | 解决动作 |
|---|---|---|
fatal error: opencv2/opencv.hpp: No such file or directory | 编译命令里没加OpenCV头文件路径 | 用pkg-config或cmake的include_directories显式指定 |
undefined reference to cv::imread(...) | 有头文件但没链接库 | 检查target_link_libraries是否包含了${OpenCV_LIBS} |
libopencv_core.so.3.2: cannot open shared object file | 程序链接了3.2库，但系统里该库不可见 | 检查ldd输出，sudo ldconfig刷新缓存，或用LD_LIBRARY_PATH指定路径 |
OpenCV(4.x) ... error: Assertion failed | 程序运行的是4.x库但接口使用习惯仍是3.x | 检查代码里是否使用了已废弃API，按新接口改写 |
ROS节点启动时崩溃，报cv::Mat相关错误 | cv_bridge与程序链接的OpenCV版本不匹配 | 统一版本，或按第4.4节重新编译cv_bridge |
python3 import cv2 ImportError: No module named 'cv2' | Python路径里没有cv2模块 | 在conda环境里执行pip install opencv-python |
import cv2; cv2.__version__显示3.2而不是4.x | import混乱，导入了系统路径的cv2 | 检查cv2.__file__路径，调整PYTHONPATH或虚拟环境 |
5.2 三个排查命令，救命的“三板斧”
遇到OpenCV相关疑难杂症时，我习惯先跑三个命令确认当前系统状态，再决定怎么动手：
# 看当前系统能找到哪些OpenCV版本 pkg-config --modversion opencv pkg-config --modversion opencv4 # 看实际库文件版本 ls -l /usr/local/lib/libopencv_core.so* ls -l /usr/lib/x86_64-linux-gnu/libopencv_core.so* # 看程序实际加载了哪个库 ldd your_program | grep opencv第一条命令确认pkg-config是否找到了多个版本，第二条命令确认两套库是否共存，第三条命令直接定位程序链接的库文件和路径。绝大部分冲突问题，靠这三条命令就能排查出七八分。
5.3 意外的“元凶”：GCC版本与C++标准
还有一个容易被忽略的坑，和OpenCV与ROS的冲突无关，但和Ubuntu 18.04的环境强相关：编译OpenCV 4.5.x需要编译器支持C++11标准，Ubuntu 18.04默认的GCC 7.5完全没问题。可如果你用conda环境执行g++，conda可能会把编译器切换到新版GCC（比如10.x），这时候某些老ROS包的编译反而可能因为新编译器太严格而失败。
解决办法是在需要编译ROS功能包时，显式指定编译器版本：
export CC=/usr/bin/gcc export CXX=/usr/bin/g++这两个环境变量告诉cmake使用系统默认的GCC 7.5，而不是conda环境里的新版GCC。这个小细节能避免很多“莫名其妙就编译失败”的问题。
5.4 我踩过的一个最隐蔽的坑：环境变量残留
最后讲一个我亲身经历过的隐蔽问题。某次我在/etc/ld.so.conf.d/里创建了一个自定义conf文件，内容指向/usr/local/lib，本意是想让自定义库生效，结果这个文件让系统里所有程序在启动时都优先加载了/usr/local/lib下的libopencv_core.so.4.5。ROS节点启动时加载cv_bridge的3.2库，但cv_bridge依赖的libopencv_core.so被劫持成了4.5版本，结果惨不忍睹。
排查这个问题的过程相当痛苦，ldd查出来的是3.2库存在，但程序一跑就崩。后来才发现是/etc/ld.so.conf.d/下的加载顺序在作怪。从此之后，我给自己立了条规矩：不轻易改全局ld配置，自定义库路径一律放在用户级LD_LIBRARY_PATH里，并严格做到按项目单独设置，不在~/.bashrc里写死全局路径。
排查这个问题的过程相当痛苦，ldd查出来的是3.2库存在，但程序一跑就崩。后来才发现是/etc/ld.so.conf.d/下的加载顺序在作怪。从此之后，我给自己立了条规矩：不轻易改全局ld配置，自定义库路径一律放在用户级LD_LIBRARY_PATH里，并严格做到按项目单独设置，不在~/.bashrc里写死全局路径。
6. 实操心得补充：两个高效小工具
6.1 版本切换神器：update-alternatives
如果你需要在系统中频繁切换OpenCV版本（比如有时编译ROS插件，有时做纯算法实验），可以考虑使用update-alternatives管理头文件和CMake配置。这个工具本来是管理默认命令版本的，但同样适用于管理OpenCV的cmake配置链接。
思路是：把/usr/local/lib/cmake/opencv4和/usr/lib/x86_64-linux-gnu/cmake/opencv3分别注册为alternatives，然后随时切换默认OpenCV_DIR的指向。不过这个方案操作复杂度偏高，且对CMake工程的支持并不完美，实际运维成本比较大。我自己试过一段时间后放弃了这个做法，最终还是回到了第4.5节的物理隔离方案。如果你不是有极高的切换频率需求，不建议在这个方向上投入过多时间。
6.2 Docker方案：一劳永逸的终极隔离
如果你愿意尝试容器化开发，Docker可能是解决OpenCV和ROS冲突的最干净方式：在镜像里分别构建ROS环境和OpenCV 4环境，运行多个容器互相隔离。
但Docker方案也有一个让人头疼的问题：GUI显示和摄像头直通。你需要额外配置X11转发（把宿主机的显示接口挂给容器）和/dev/video0设备映射，一度让我觉得配置时间比写代码时间还长。如果你的项目里不涉及实时视频流和GUI预览，纯算法开发用Docker很省心；一旦需要跑摄像头和显示窗口，还是老老实实本地装吧。
从个人经验来看，做长期维护的机器人项目，本地物理隔离方案总是最可控的选择。
后期如果项目迭代方向和团队协作方式变化，可以从容器化逐步过渡，把环境配置固化成Dockerfile或Ansible脚本，那其实是另一个值得深入的话题了。我个人在实际操作中的体会是：环境搭建没有一劳永逸的银弹，但把“路径隔离、版本显式化、环境变量最小化”这三个原则执行到位，至少能解决掉八成以上的OpenCV和ROS冲突问题，剩下的该翻文档翻文档，该看源码看源码，事情总会做得下去的。
