必须运行sudo ldconfig，否则/etc/ld.so.conf配置无效；系统只读取由ldconfig生成的/etc/ld.so.cache缓存，不实时扫描磁盘路径。
改完 /etc/ld.so.conf 或 /etc/ld.so.conf.d/*.conf 后不运行 sudo ldconfig，配置就等于没写——这是 90% 的人卡住的第一步。
为什么改了 /etc/ld.so.conf 还是找不到库？
因为 ld.so.conf 只是配置源，真正起作用的是二进制缓存文件 /etc/ld.so.cache，它由 ldconfig 生成。系统加载动态库时只读这个缓存，不实时扫描磁盘。
- 常见错误现象：
./a.out: error while loading shared libraries: libxxx.so: cannot open shared object file，但你确认库就在刚加的路径里 - 必须用
sudo ldconfig（普通用户权限不够） - 建议加
-v参数验证是否真扫到了路径：sudo ldconfig -v 2>&1 | grep your_path - 如果路径出现但库没列出来，检查：库文件权限是否至少为
rx、是否为 ELF 格式（file libxxx.so）、架构是否匹配（比如 x86_64 库不能用在 arm64 系统上）
该往 /etc/ld.so.conf.d/ 里写什么？
只写绝对路径，一行一个，不能带通配符、不能写具体库名、不能有空格或 # 注释（# 在这里会被当路径名的一部分）。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 正确示例：
/usr/local/lib64、/opt/myapp/lib - 错误写法：
/home/user/lib（系统级链接器默认不信任用户目录，且多用户环境下不可靠） - 推荐做法：新建
/etc/ld.so.conf.d/myapp.conf（文件名任意，但必须以.conf结尾），写入路径后执行sudo ldconfig - 不要直接编辑
/etc/ld.so.conf主文件——容易误操作，卸载软件时也不好清理
LD_LIBRARY_PATH 和 ld.so.conf 谁生效？
LD_LIBRARY_PATH 优先级更高，但它只影响当前 shell 及其子进程；ld.so.conf 是系统级配置，需 ldconfig 刷新，生效范围广但无运行时灵活性。
- 临时调试：用
LD_LIBRARY_PATH=/path/to/lib ./myapp - 部署服务（如 systemd、crond）：必须走
/etc/ld.so.conf.d/+sudo ldconfig，否则服务根本看不到你的路径 - 混合使用时注意冲突：比如
LD_LIBRARY_PATH里有同名库，会覆盖ld.so.conf中的版本，可能引发 ABI 不兼容 -
LD_LIBRARY_PATH对 setuid 程序完全无效（安全限制）
怎么确认新加的库真被系统认了？
ldconfig -p 显示的是当前 /etc/ld.so.cache 缓存里的库列表，不是实时磁盘扫描结果。
- 查不到刚加的库？先确认
sudo ldconfig是否成功执行（看输出是否有你的路径） - 再检查库命名是否合规：必须是
lib{name}.so.{x}格式（如libz.so.1.2.11），链接时才支持-lz - 用
ldd ./myapp直接看程序实际依赖哪些库、是否已解析成功 - 若仍失败，用
strace -e trace=openat ./myapp 2>&1 | grep so观察运行时到底去哪些路径尝试打开库文件
最易忽略的其实是库文件本身：命名不规范、缺少 soname、权限不对、架构错位——这些比路径配置更早拦住加载过程。
