yum clean all 会一次性清除全部 yum 缓存，既包含仓库元数据，也包含已下载的 .rpm 软件包缓存，但通常并不建议频繁这样操作；在 CentOS 清理 yum 缓存的实际使用中，更常见、也更高效的方式其实是 yum clean packages（仅删除 .rpm 包缓存，保留元数据，后续执行安装和查询会更快）以及 yum clean metadata（只刷新元数据，适合 yum 源发生变化，或出现相关报错时使用）。完成清理后，建议立即执行 yum makecache，及时重建缓存。
yum clean all 的确可以删除所有 yum 缓存文件，但大多数情况下并没有这个必要——因为它会把元数据也一起删除，导致下次执行 yum install 或 yum search 时必须重新下载索引，从而明显拖慢操作效率。更合理的做法，是根据实际需求按需清理 yum 缓存。
只删 rpm 包缓存，保留元数据
yum clean packages 是一条经常被忽视、但非常实用的 yum 清理命令。它只会清除 /var/cache/yum/*/packages/ 目录中已经下载但尚未安装的 .rpm 缓存文件，而保留 repodata/ 中的仓库元数据不变。这样既能释放大量磁盘空间（通常这部分会占 yum 缓存的 80% 以上），又不会影响后续的软件包搜索、依赖分析和安装速度。
- 适用场景：服务器磁盘空间不足，但又不想花时间重新生成 yum 元数据缓存
- 注意：keepcache=1（默认）时才会保留包缓存；如果设置为 0，那么此命令基本不会产生效果
- 查看占用：可运行 du -sh /var/cache/yum/*/packages 先确认缓存目录的实际大小
只刷新元数据，不碰 rpm 包
yum clean metadata 适用于 yum 源地址变更、镜像站同步延迟，或者遇到 Cannot retrieve metalink for repository 等错误提示时。它删除的是 repodata/ 目录中的 repomd.xml、primary.xml.gz 等索引文件，目的是强制 yum 在下次执行时重新获取最新的仓库元数据结构。
- 常见错误现象：yum list a vailable 仍显示旧版本，或执行 yum update 时找不到最新软件包
- 不要混用：执行 yum clean metadata 后最好立刻运行 yum makecache，否则后续 yum 命令可能会停留在“retrieving”阶段
- 避免在批量部署脚本中无条件调用——元数据重建依赖网络 IO，可能导致超时或失败
手动删缓存前必须确认的三件事
直接使用rm -rf /var/cache/yum/* 看起来最彻底，但实际风险并不小：
- 如果在 yum 进程正在写入缓存时执行，可能破坏目录结构，导致后续运行 yum 报错：IOError: [Errno 2] No such file or directory
- 某些插件（例如 fastestmirror）会依赖 timedhosts 文件，删除后可能影响镜像源选择逻辑
- /var/cache/yum 目录下可能存在非空子目录（如 plugins/），直接 rm -rf 会把插件状态文件一并清掉
- 正确方式：先停止所有 yum 相关进程（ps aux | grep yum），再执行 yum clean all，最后通过 ls -la /var/cache/yum 检查是否只保留空的目录结构
清理后不重建缓存，等于白清
yum clean all 或 yum clean metadata 执行完成后，如果没有马上跟上 yum makecache，那么第一次运行 yum install 往往会卡顿十几秒甚至几分钟，而且通常看不到明确的进度提示。这不是程序 bug，而是 yum 的默认机制：它会在下载仓库信息的同时重建缓存，在这个过程中甚至可能对 Ctrl+C 没有及时响应。
- 生产环境建议：清理 yum 缓存后立即执行 yum makecache --quiet（加上 --quiet 可减少输出干扰）
- 如果网络环境不稳定，可追加 --setopt=metadata_expire=0，强制跳过本地元数据过期检查
- 注意：yum repolist 同样会触发缓存重建，但输出内容更冗长，不如直接使用 makecache 更简洁
真正需要关注的重点，并不是“把 yum 缓存删得多彻底”，而是“是否在合适的时机，以可控的方式完成清理”。/var/cache/yum 中的元数据往往比 rpm 包缓存更关键——它直接决定你能搜索到哪些软件包，以及依赖关系能否正确解析。盲目执行 yum clean all 看似简单省事，实际上会把 yum 缓存机制带来的效率优势全部抵消。
