/usr/lib64专存64位程序的共享库，/usr/lib主要存32位库及多架构兼容库；二者按程序架构严格区分，由编译时目标决定运行时查找路径，非按重要性或新旧划分。
这两个目录不是按“重要程度”或“新旧”划分的，而是严格按程序架构和运行时依赖关系来定位的。
/usr/lib64 是 64 位程序的默认库路径
在主流 x86_64 系统中，/usr/lib64 是编译为 x86_64 架构的程序（比如大多数现代桌面应用、服务进程）在运行时查找共享库的首要位置。动态链接器（如 ld-linux-x86-64.so.2）会默认将它纳入搜索路径。
- 64 位程序启动时，系统优先从 /usr/lib64 加载 .so 文件
- 软件包管理器（如 dnf、zypper）安装 64 位软件时，其依赖库自动放进 /usr/lib64
- 你用 file 命令检查一个二进制文件，若显示 “ELF 64-bit LSB shared object, x86-64”，它大概率会找 /usr/lib64 下的对应库
/usr/lib 主要承载 32 位库与多架构兼容场景
虽然名字叫 “lib”，但它在 64 位发行版里并不存放“通用”或“老版本”库，而是一个有明确职责的架构专用路径。
- 32 位程序（i686 或 i386）运行时，默认查找 /usr/lib 中的 .so 文件
- 某些 64 位系统启用 multiarch 支持后，/usr/lib 也会存部分 ABI 兼容库（如 libgcc_s.so.1 的 32 位副本），供混合环境调用
- 少数跨架构工具链（如交叉编译器）可能把目标平台的库放在这里，但需配合 LD_LIBRARY_PATH 或 linker script 显式指定
路径选择由编译阶段决定，而非运行时猜测
一个程序最终去哪个目录找库，不是靠系统“判断”，而是编译时就写死在 ELF 的 DT_RUNPATH 或 DT_RPATH 字段里，或者由链接器根据目标架构自动推导。
- 用 gcc -m64 编译 → 默认链接 /usr/lib64 下的库，生成的可执行文件记录该路径
- 用 gcc -m32 编译 → 即使在 64 位系统上，也会链接 /usr/lib，并在运行时查那里
- pkg-config --libs xxx 返回的 -L 参数，往往直接指向 /usr/lib64 或 /usr/lib，取决于所选 pkgconfig 文件
别混淆符号链接和实际用途
有些发行版（如较新 Fedora 或 openSUSE）让 /lib 指向 /usr/lib、/lib64 指向 /usr/lib64，但这只是归并物理存储，并不改变语义分工。/usr/lib 仍是 32 位程序的逻辑归属地，/usr/lib64 仍是 64 位程序的逻辑归属地。
- ls -l /usr/lib64 显示它通常是个真实目录，不是软链
- 即使 /lib → /usr/lib，/lib64 → /usr/lib64，也不代表两者可以混用
- 强行把 64 位 so 放进 /usr/lib，会导致 64 位程序找不到依赖（除非额外配置）
