最常见原因是清理缓存后未重建元数据；元数据是包管理器定位、校验软件的“地图”，必须与远程仓库一致，故执行yum clean all后务必紧跟yum makecache。
清理缓存后不重建元数据，是 yum/dnf 报错“Failed to synchronize cache for repo”最常见原因。元数据不是可选附件，而是包管理器定位、校验和安装软件的“地图”，必须与远程仓库状态一致。
先看缓存占多少，再决定怎么清
盲目执行 yum clean all 可能白忙一场——实际占用空间的未必是 yum 缓存本身：
- 用
du -sh /var/cache/yum查真实体积；若只有几十 MB，问题大概率不在这里 - 运行
journalctl --disk-usage，systemd 日志常静默占用 1–3 GB，比 yum 缓存更易被忽略 - 检查
df -h /和df -h /var，确认是否被旧内核（/boot）、docker 镜像或日志挤占根分区
分步清理比全删更安全高效
yum clean all 是重置操作，适合换源或修复异常；日常维护推荐按需清理：
-
yum clean packages：只删已下载的 .rpm 文件，保留 repomd.xml 等元数据，下次安装跳过元数据拉取，速度快且无风险 -
yum clean metadata：只删元数据，适合刚修改/etc/yum.repos.d/后刷新仓库结构，但几乎不释放磁盘空间 -
yum clean expire-cache：触发 yum 主动检查元数据有效期并丢弃过期项，比clean metadata更智能
清理后必须重建元数据缓存
清完不跑 yum makecache，后续所有操作都会卡在 “Downloading package metadata…”：
-
yum makecache默认只下载元数据（不碰 .rpm），通常 2–5 秒完成，务必紧跟在clean packages后执行 - 遇到慢源可临时延长超时：
yum makecache --setopt=timeout=120 - 内网离线环境可设永不过期：
yum makecache --setopt=metadata_expire=never（仅限可信环境）
异常残留要手动干预
中断或错误操作后，/var/cache/yum 下可能残留损坏的 cache.db 或空 packages/ 目录，导致同步失败：
- 清理后执行
ls -l /var/cache/yum，正常应只剩.和..；若存在子目录，逐个检查内容 - 发现损坏数据库或半下载文件，直接
sudo rm -rf /var/cache/yum/<repo-name></repo-name> - 确保目录归属为
root:root，非 root 写入会导致 yum 静默失败
