不建议永久设置ld_library_path，因其易覆盖系统路径、干扰其他程序，且存在安全限制（如setuid程序会忽略它）；临时调试可用export，生产环境应优先使用/etc/ld.so.conf.d/配合ldconfig。
直接说结论：不建议永久设置 LD_LIBRARY_PATH，除非你明确知道它会覆盖系统默认路径、干扰其他程序，且无法用更安全的方式替代。临时调试可以，生产环境优先走 /etc/ld.so.conf.d/ + ldconfig。
为什么 export LD_LIBRARY_PATH 在新终端里不生效
因为 export 只影响当前 shell 进程及其子进程，关闭终端或新开一个 shell 后变量就清空了。很多人在终端里执行了 export LD_LIBRARY_PATH=/my/lib:$LD_LIBRARY_PATH，以为“设好了”，结果运行程序还是报 error while loading shared libraries，其实只是没进新 shell 的上下文。
- 验证是否生效：运行
echo $LD_LIBRARY_PATH，不是env | grep LD（可能残留旧值） - 临时生效的正确姿势：先
export，再在同一 shell 中运行目标程序，不要另开窗口 - 如果必须跨终端持久化，得写进 shell 初始化文件（如
~/.bashrc），并确保该文件被 source 过
永久设置时该写进 ~/.bashrc 还是 /etc/profile
取决于作用范围和权限。普通用户改 ~/.bashrc 就够了；全局生效才动 /etc/profile 或 /etc/environment，但后者不支持变量拼接语法（$LD_LIBRARY_PATH 会被当字面量）。
-
~/.bashrc：每次打开新终端都读取，适合单用户开发调试；加这行：export LD_LIBRARY_PATH="/home/user/mylib:$LD_LIBRARY_PATH" -
/etc/profile：所有用户登录 shell 都加载，需sudo权限；注意别漏掉$LD_LIBRARY_PATH原值，否则会覆盖系统默认路径 - 绝对不要直接写
LD_LIBRARY_PATH=/path（无拼接），这会丢掉/lib、/usr/lib等关键路径
LD_LIBRARY_PATH 和 /etc/ld.so.conf.d/ 的本质区别
LD_LIBRARY_PATH 是运行时由动态链接器（ld-linux.so）读取的环境变量，优先级最高，但只对当前进程有效；而 /etc/ld.so.conf.d/*.conf 是给 ldconfig 用的配置，它生成的是系统级缓存 /etc/ld.so.cache，所有程序都能用，且不依赖环境变量。
- 用
ldconfig方式：新建/etc/ld.so.conf.d/myapp.conf，写入路径（仅路径，不带变量），然后运行sudo ldconfig - 优势：无环境变量污染风险，不影响其他用户或服务，重启后依然有效
- 劣势：需要 root 权限；新增库后必须手动
ldconfig，否则缓存不更新 - 验证是否入库：
ldconfig -p | grep mylib
运行时找不到 .so 文件，但 ldd 显示路径正常
常见于程序自己 fork 出子进程、或使用 setuid 的二进制（如某些系统工具）。出于安全考虑，Linux 内核会**忽略** LD_LIBRARY_PATH 对这类进程的影响 —— 即使父进程设置了，子进程也拿不到。
- 现象：
ldd ./myapp能看到libxxx.so => /path/to/libxxx.so，但运行时报错 - 原因：该程序用了
setuid或被secure-exec机制拦截，LD_LIBRARY_PATH被内核静默丢弃 - 解法：只能走
/etc/ld.so.conf.d/+ldconfig，或者重新编译程序时用-rpath把路径硬编码进去 - 检查是否 setuid：
ls -l ./myapp，看权限位是否有s（如-rwsr-xr-x）
真正麻烦的从来不是“怎么设”，而是“设了之后谁认、谁不认、什么时候失效”。尤其是涉及容器、systemd 服务、crontab 或 setuid 程序时，LD_LIBRARY_PATH 经常悄无声息地被绕过。动手前先跑一遍 ldd，再确认目标进程的启动上下文，比反复改环境变量管用得多。
