/lib64是系统启动必需的64位核心库目录，存放ld-linux-x86-64.so.2、libc.so.6等init前必须可用的库；/usr/lib64是用户空间64位应用主库区，存放gnome、python等软件依赖库，二者逻辑分离不可合并。
/lib64 和 /usr/lib64 在大多数现代 64 位 Linux 发行版中确实内容高度重合，但它们的定位和设计意图完全不同——不是冗余，而是分层职责的体现。
/lib64 是系统启动阶段的“刚需库”
这个目录存放的是内核加载后、init 进程启动前就必须可用的共享库。因为 /usr 分区可能尚未挂载（比如它在独立磁盘或网络存储上），所以所有依赖 /usr 的路径在此时不可用。
- 必须能被 /bin/ls、/sbin/mount、/sbin/init 等根文件系统内的关键二进制调用
- 典型文件包括：ld-linux-x86-64.so.2（动态链接器）、libc.so.6、libdl.so.2
- 在多数发行版中，/lib64 实际是 /usr/lib64 的符号链接，但这仅是实现层面的优化；FHS 规范仍要求其逻辑独立性
/usr/lib64 是用户空间程序的“主库区”
它面向的是已进入完整运行环境后的应用程序，不参与早期启动链。几乎所有通过包管理器安装的 64 位软件（如 GNOME、Python、GCC 工具链）都将库安装至此。
- 存放非核心命令的依赖库，例如 libgtk-3.so.0、libpython3.11.so.1.0
- RPM 系发行版（CentOS/RHEL/Fedora）明确将 /usr/lib64 作为默认库目标；Debian/Ubuntu 则倾向使用 /usr/lib/x86_64-linux-gnu，但语义等价
- 允许管理员或打包工具安全地增删内容，不影响系统启动稳定性
为什么看起来“重叠”，又为何不能简单合并？
重叠源于实际部署效率：把基础库和应用库物理共存于同一路径，可减少磁盘占用与维护成本。但逻辑隔离必须保留——否则一旦 /usr 挂载失败，系统将无法完成初始化。
- 若强行删除 /lib64 或取消其独立存在，可能导致 init 进程找不到 libc 而 panic
- 若把大型应用库（如 Qt 或 CUDA）放进 /lib64，则违反 FHS，且增大 rootfs 风险
- 检查方式：运行 find /lib64 -type f | head -5 和 find /usr/lib64 -type f | head -5，会发现前者精简固定，后者庞杂多变
实际运维中的关键提醒
不要手动向 /lib64 写入第三方库；也不建议为兼容性把 64 位程序硬链接到 /usr/lib。正确做法是：
- 第三方库优先放 /usr/local/lib64，再通过 /etc/ld.so.conf.d/ 注册并运行 ldconfig
- 确认程序依赖路径：用 ldd /path/to/binary 查看具体加载来源，而非只看目录名
- 区分符号链接真实指向：readlink -f /lib64 和 readlink -f /usr/lib64，不同发行版策略不同
