libcudart.so.11.0找不到？别急着重装CUDA——先读懂Linux动态链接器在“找谁”、怎么找、为什么找不到
你刚 pip install 好 PyTorch，执行import torch却突然弹出：
ImportError: libcudart.so.11.0: cannot open shared object file: No such file第一反应可能是：“我明明装了 CUDA 11.0，库文件就在/usr/local/cuda-11.0/lib64/，为什么找不到？”
这不是你的错。
也不是 PyTorch 故意刁难。
更不是ldconfig失灵了。
真正的问题在于：你的 Python 进程启动时，Linux 动态链接器根本没去那个目录下找libcudart.so.11.0—— 它压根不知道该去哪找。
而这个“不知道”，恰恰是 Linux 系统设计中最精妙也最容易被误解的一环：动态库的解析不是靠“路径存在”，而是靠一套有严格优先级、可被编译期固化、运行时继承、还能被环境变量覆盖的搜索机制。
我们来拆解这个错误背后的完整链路——不讲抽象概念，只说你终端里敲得出、看得见、改得动的真实行为。
你以为它在找文件，其实它在查“契约”
当你运行python -c "import torch"，背后发生的是这样一段精密协作：
- Python 加载
_C.cpython-38-x86_64-linux-gnu.so（PyTorch 的 C++ 后端）； - 操作系统读取这个
.so文件的 ELF 头，发现它声明了一个硬性依赖：DT_NEEDED libcudart.so.11.0； - 关键来了：链接器
ld-linux-x86-64.so.2开始按固定顺序查找这个 soname（不是文件名！是SONAME字段值），顺序如下：
- ✅ 第一优先级：.so文件自己带的RUNPATH（编译时用-rpath写死的路径）
- ✅ 第二优先级：进程环境变量LD_LIBRARY_PATH（冒号分隔的目录列表）
- ✅ 第三优先级：系统缓存/etc/ld.so.cache（由ldconfig生成）
- ❌ 最后兜底：/lib64、/usr/lib64（通常没有libcudart.so.11.0）
