不建议永久设置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 跑一遍，再把目标进程的启动上下文核实清楚，这通常更有效。
