ldconfig -p 显示的是缓存路径，不是实时磁盘扫描结果：它读取 /etc/ld.so.cache 中由 /etc/ld.so.conf 和 /etc/ld.so.conf.d/*.conf 配置生成的已知库路径集合，反映系统当前“认得”的库，而非实时遍历磁盘。
ldconfig -p 显示的是缓存路径，不是实时磁盘扫描结果
运行 ldconfig -p 输出的，是动态链接器当前“认得”的库路径集合——它来自 /etc/ld.so.cache，由 /etc/ld.so.conf 和 /etc/ld.so.conf.d/*.conf 中声明的目录生成。这不是对磁盘的实时遍历，所以快、稳定、反映的是系统配置生效后的状态。
常见误判：刚把 /opt/mylib 写进 /etc/ld.so.conf.d/mylib.conf，立刻跑 ldconfig -p | grep libxxx 找不到——大概率因为没执行 sudo ldconfig 刷新缓存，或配置文件权限/格式不对（必须是纯文本、每行一个绝对路径、无空格或注释）。
- 确认配置已写入：
cat /etc/ld.so.conf.d/mylib.conf应输出类似/opt/mylib - 刷新必须用
sudo ldconfig，普通用户执行无效果 -
ldconfig -p | head -n 10可快速看前几条，验证是否加载成功
LD_LIBRARY_PATH 是运行时临时覆盖路径，只对当前 shell 生效
这个环境变量不改系统配置，只影响当前 shell 及其子进程的库搜索顺序，优先级高于系统默认路径。适合调试或 CI 环境中临时指定非标路径。
但容易踩坑：设了 LD_LIBRARY_PATH="/opt/mylib" 后程序能跑，不代表部署就 OK——换终端、换用户、做成 systemd 服务时变量不会自动继承。
- 临时生效：
LD_LIBRARY_PATH="/opt/mylib:$LD_LIBRARY_PATH" ./myapp - 不要
export LD_LIBRARY_PATH到~/.bashrc，否则可能干扰其他程序加载同名库 - 使用前先
echo $LD_LIBRARY_PATH，空值或拼错路径不会报错，只会静默跳过 - 配合
ldd ./myapp看输出里有没有not found行，判断当前路径是否真被识别
readelf -d 查看可执行文件内嵌的 RPATH/RUNPATH
编译时用 -Wl,-rpath,/path/to/lib 嵌入的路径，会直接写进 ELF 文件的 .dynamic 段，运行时优先于系统配置和环境变量。这是最可靠、最干净的部署方式之一。
查这个路径不用依赖外部配置，只要文件本身没被 strip 过：
-
readelf -d ./myapp | grep -E "(RPATH|RUNPATH)"—— 输出类似0x000000000000001d (RPATH) Library rpath: [/opt/myapp/lib] - RPATH 是旧标准，RUNPATH 是新标准（优先级略低，但支持 $ORIGIN 等 token）
- 若看到
$ORIGIN/../lib这类相对路径，说明程序设计为与自身位置相关联查找库 - 注意：strip 后该信息可能丢失，
readelf -d会返回空
strace 跟踪真实 openat 调用，看清链接器实际去哪找
当 ldd、pldd、ldconfig -p 都无法解释“为什么找不到”，就得看动态链接器真正尝试打开哪些路径——strace 是唯一能揭示这一层行为的工具。
它不依赖缓存或配置，直接捕获系统调用，代价是启动开销大、输出冗长：
strace -e trace=openat,open -f ./myapp 2>&1 | grep '\.so'- 重点看
openat(AT_FDCWD, "/xxx/libxxx.so", ...)这类行，确认链接器到底试了哪些路径 - 若出现
ENOENT（No such file），对应路径就是失败点；若出现EACCES，则是权限问题 - 注意过滤掉内核伪路径（如
[vdso]、[vvar]），它们不是真实文件
真正难排查的问题，往往卡在 RPATH 解析失败、$ORIGIN 展开错误、或容器挂载导致路径映射错位——这些细节，只有 strace 能一锤定音。
