根本原因是TensorFlow编译时硬编码依赖特定版本libcudnn.so（如8.6.0），而系统中cuDNN版本不匹配或LD_LIBRARY_PATH指向错误路径；应通过隔离的LD_LIBRARY_PATH启动或patchelf修改rpath解决。
为什么 import tensorflow 会报 ImportError: libcudnn.so.8: cannot open shared object file
这不是 Python 包冲突，而是底层 CUDA/cuDNN 动态库被多个 TensorFlow 版本（比如 tf-nightly 和 tensorflow==2.12.0）各自尝试链接不同版本的系统库导致的。TensorFlow 编译时硬编码了它期望的 libcudnn.so.8 或 libcudnn.so.9 路径，而系统里可能只装了其中一个，或者多个版本共存但 LD_LIBRARY_PATH 指向了不匹配的那个。
- 典型现象：一个虚拟环境里能 import 成功，换另一个就崩；
nvidia-smi显示驱动正常，但 TF 报找不到 cuDNN - 根本原因不是 pip install 冲突，而是
libtensorflow_framework.so等内部 so 文件在运行时动态绑定失败 - 不要试图用
conda install cudnn=8.6全局覆盖——不同 TF 版本对 CUDA Toolkit 和 cuDNN 的 ABI 兼容性是严格限定的（查官方 GPU 支持表）
用隔离的 LD_LIBRARY_PATH 启动每个 Python 进程
最稳妥的做法不是“统一系统库”，而是让每个 TF 环境只看到它自己能用的那套库。不用改系统全局配置，也不用重装驱动。
- 先确认你有哪些 CUDA/cuDNN 安装路径：
find /usr -name "libcudnn.so*" 2>/dev/null，通常在/usr/lib/x86_64-linux-gnu/或/usr/local/cuda-11.8/lib64/下 - 为
tensorflow==2.12.0（需 CUDA 11.8 + cuDNN 8.6）新建启动脚本：#!/bin/bash export LD_LIBRARY_PATH="/usr/local/cuda-11.8/lib64:/usr/local/cuda-11.8/lib64/libcudnn.so.8:$LD_LIBRARY_PATH" exec "$@"
- 运行时包装：
./tf212-env.sh python train.py，这样import tensorflow就只会加载 cuDNN 8.6，不会误碰系统里其他版本 - 注意：不要把
LD_LIBRARY_PATH写进~/.bashrc—— 一旦设成全局，所有 Python 进程都会受干扰
用 patchelf 修改已安装 wheel 的 rpath（高级但有效）
如果你已经 pip install 了某个 TF 版本，但它死活找不到对应 cuDNN，可以强行把它“绑”到你本地存在的库路径上。这比重装 wheel 更快，且不影响其他环境。
- 先找到 wheel 解压后的 so 文件：
python -c "import tensorflow as tf; print(tf.__file__)"; ls $(dirname $(python -c "import tensorflow as tf; print(tf.__file__)"))/python/_pywrap_tensorflow_internal.so - 用
patchelf替换 runtime path：patchelf --set-rpath '/usr/local/cuda-11.8/lib64:/usr/local/cuda-11.8/lib64/libcudnn.so.8' _pywrap_tensorflow_internal.so
- 验证是否生效：
readelf -d _pywrap_tensorflow_internal.so | grep PATH，应显示你刚设的路径 - 风险提示：修改二进制文件后，该 wheel 不再是官方签名版本；升级 TF 前记得删掉这个 patch，否则新版本可能被污染
别忽略 cuda-toolkit 和 cudnn 的版本号小数点差异
TensorFlow 对 cudnn 8.6.0 和 cudnn 8.6.1 是不兼容的——哪怕只差一个 patch 版本。官方文档写的 “cuDNN 8.6” 实际指 8.6.0，不是 “8.6.x”。
立即学习“Python免费学习笔记（深入）”；
- 检查真实版本：
cat /usr/local/cuda-11.8/include/cudnn_version.h | grep CUDNN_MAJOR -A 2 - 如果系统里是
cudnn 8.6.1，但 TF 2.12 需要8.6.0，别指望软链libcudnn.so.8 → libcudnn.so.8.6.1能 work —— 它会校验 soname 和内部 version 字符串 - 解决方案只有两个：降级 cuDNN 到精确匹配版本，或换用支持该 cuDNN 版本的 TF（比如 TF 2.13 支持 cuDNN 8.6.1）
真正麻烦的从来不是装几个 pip 包，而是每个 .so 文件背后那一长串 DT_NEEDED 和 RPATH 依赖链。动了哪一环，就得清楚它影响的是哪个 loader、哪个 dlopen 调用、哪个符号解析阶段。
