/lib存放系统启动必需的核心库（如libc.so.6），确保根分区可自举；/usr/lib存放用户空间程序所需的非启动级库，由包管理器默认安装。
Linux 中 /lib 和 /usr/lib 不是简单按“大小”或“新旧”划分的存放目录，而是由系统启动阶段、依赖关系和 FHS（文件系统层次结构标准）共同定义的职责分工。它们直接影响动态链接器（ld-linux.so）在程序启动时如何查找和加载共享库。
/lib：系统自举必需的核心库
这个目录存放的是被 /bin 和 /sbin 下基础命令直接依赖的共享库，例如 libc.so.6、libpthread.so.0、ld-linux-x86-64.so.2。这些命令必须在 /usr 分区挂载前就能运行——比如 init、fsck、ls、mount 等。
- 根分区必须包含
/lib（或/lib64），否则系统无法完成早期初始化 -
/lib通常为/lib64的符号链接（64 位系统），实际核心库放在/lib64 - 手动增删其中文件风险极高，可能导致系统无法启动
- 可通过
ldd /bin/ls查看其依赖路径，结果几乎全指向/lib或/lib64
/usr/lib：用户空间程序的运行时库
/usr/lib 是绝大多数应用程序（如 /usr/bin/python3、/usr/bin/gcc、/usr/lib/systemd）所依赖的共享库所在位置。这些程序只在基础系统就绪、/usr 可访问后才启用。
- 不参与系统引导，因此可置于独立分区、只读挂载点甚至网络存储上
- 包管理器（apt/dnf/yum）安装的第三方软件库默认落在此处
- 支持架构子目录，如
/usr/lib32（32 位兼容）、/usr/lib/x86_64-linux-gnu（Debian/Ubuntu 风格） - 用
ldd /usr/bin/python3可验证其依赖多来自/usr/lib及其子目录
动态链接器如何查找这两个目录
程序启动时，动态链接器（ld-linux.so.*）按固定顺序搜索共享库：
- 先检查可执行文件的
DT_RUNPATH或DT_RPATH（编译时通过-Wl,-rpath指定） - 再查环境变量
LD_LIBRARY_PATH（仅对当前 shell 有效） - 然后读取
/etc/ld.so.cache—— 这是ldconfig根据/etc/ld.so.conf及其包含的配置（如/etc/ld.so.conf.d/*.conf）生成的二进制索引 - 若仍未命中，则**硬编码 fallback 路径**：
/lib和/usr/lib（注意：不递归子目录）
也就是说，/lib 和 /usr/lib 是最后兜底的两个路径，但它们被内建在链接器中，无需额外配置即可生效。
新增库路径的正确做法
当第三方库（如安装在 /usr/local/lib 或自定义路径）需要被系统识别时，不能靠复制文件到 /lib 或 /usr/lib（易冲突、难维护），应优先使用以下方式：
- 将路径写入
/etc/ld.so.conf.d/myapp.conf，再运行sudo ldconfig更新缓存 - 开发阶段可用
export LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH临时生效 - 编译时用
gcc -Wl,-rpath,/path/to/lib将路径写入可执行文件，最可靠且不依赖环境
无论哪种方式，只要涉及 /lib 或 /usr/lib 内容变更（如新增 .so 文件），都必须运行 ldconfig，否则新库不会进入 /etc/ld.so.cache，链接器将找不到它。
