OpenCV 与 TensorFlow 因共享库（如 libjpeg）版本冲突导致 imread 返回 None、segfault 等问题；根本原因是动态链接时 ABI 不兼容，而非 import 顺序；推荐降级 OpenCV 或使用 conda-forge 统一管理依赖。
imread 返回 None、ImportError: undefined symbol、程序启动即 segfault —— 这些不是 OpenCV 没装好，而是 TensorFlow 和 OpenCV 在底层共享库（尤其是 libjpeg、libpng、libtiff）上发生了二进制链接冲突。根本原因不是 Python 层 import 顺序，而是二者动态链接时加载了不兼容的同一系统库版本。
为什么 import 顺序不管用？
网上流传“把 import tensorflow 放在 import cv2 前面就能解决”是误导。Python import 顺序只影响模块加载时机，不改变已加载的 C 共享库符号表。一旦 OpenCV 动态链接了某个 libjpeg.so.62，而 TensorFlow 内部期望的是 libjpeg.so.8，运行时就会崩溃或静默失败（比如 cv2.imread("xxx.jpg") 返回 None 却不报错）。
降级 OpenCV 是最快验证手段
不是所有版本都踩坑，但高版本（如 opencv-python==4.5.0+）更大概率使用较新的 libjpeg 构建，与旧版 TensorFlow 二进制不兼容。实测有效组合包括：
pip uninstall opencv-python-
pip install opencv-python==4.1.0.25（稳定兼容 TF 1.x / 2.4–2.7） - 若用 TF 2.10+，可尝试
opencv-python==4.8.1.78（需同步确认 numpy 版本）
注意：不要混用 opencv-python 和 opencv-contrib-python，后者可能引入额外 ABI 不兼容项。
conda 环境下优先走 conda-forge 渠道
pip 和 conda 混用是多数冲突的温床。conda-forge 提供预编译的统一 ABI 兼容包，比 PyPI wheel 更可靠：
立即学习“Python免费学习笔记（深入）”；
conda remove opencv-pythonconda install -c conda-forge opencv- 配套安装：
conda install -c conda-forge tensorflow（GPU 版加tensorflow-gpu）
conda 会自动协调 libjpeg、libpng 等底层依赖版本，避免 pip 安装时各自为政。
终极方案：静态链接 TensorFlow（仅限源码编译）
如果你必须用最新 OpenCV 且无法换环境，唯一根治法是让 TensorFlow 不动态链接系统 libjpeg：
- 编译时加
--config=monolithic（TensorFlow 2.8+ 已弃用该 flag，需回退到 2.7 或使用 Bazel 自定义 build） - 命令示例：
bazel build --config=monolithic -c opt //tensorflow:libtensorflow.so - 效果：生成的
libtensorflow.so内含静态libjpeg，彻底隔离冲突
但该方案成本高——需完整编译环境、数小时构建时间，且无法用于 pip 安装的预编译 wheel。
真正麻烦的从来不是哪个命令能“一键修复”，而是你得先判断当前环境用的是 pip 还是 conda、底层 libc 和 CUDA 版本是否匹配、OpenCV 是不是从官网下载的非标 wheel。这些细节不查清楚，换十个版本也白搭。
