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