Composer镜像仓库维护_学会定时清理缓存垃圾

不少开发者对Composer的缓存清理存在误解，以为一条composer clear-cache就能解决所有“缓存”问题。今天，我们就来彻底厘清这个命令的边界，以及如何聪明地管理缓存，而不是简单地“一清了之”。

composer clear-cache 到底清哪些子目录

这个命令的清理范围非常明确，它只针对composer config --global cache-dir这个全局配置所指向的路径。在这个路径下，它会固定清理三个子目录：

• files/：存放所有已下载的依赖包压缩文件（如.zip、.tar）。
• repo/：保存远程仓库的元数据快照，比如从packagist.org拉取的packages.json索引文件。
• vcs/：存储从Git、SVN等版本控制系统克隆下来的裸仓库。

这里有个关键点：它绝对不会触碰你项目里的vendor/目录、composer.lock或composer.json文件。同样，像PHP OPcache、持续集成（CI）环境中挂载的持久化卷，或者第三方镜像服务的CDN缓存，也完全不在它的职责范围内。

为什么清完缓存后 composer install 变慢了

这不是命令出了错，而是完全符合预期的行为。清理缓存本质上是用时间换空间，或者为了解决特定问题。具体来说：

• 删除了repo/目录？那么下次执行composer update或install时，Composer必须重新向Packagist发起HTTP请求，获取完整的packages.json索引。这个首次请求会带来明显的延迟，通常需要2到5秒。
• 清空了vcs/目录？当你安装那些指向Git分支（如dev-main）或尚未打标签的包时，Composer需要重新克隆整个裸仓库，这会增加大量的磁盘I/O操作。
• 移除了files/里的压缩包？虽然不影响本地解压速度，但后续安装时所有依赖包都需要重新从网络下载，对带宽是个考验。

所以，感觉变慢是正常的，这恰恰说明缓存之前正在起作用。

定时清理该删什么、不该删什么

很多人在脚本里粗暴地执行rm -rf ~/.composer/cache，这往往会拖慢后续的构建流程。更稳妥的做法是按需、精准地清理：

• 定期清理老旧压缩包：可以使用类似find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete的命令，删除90天前的旧包，释放磁盘空间。
• 安全清理废弃的Git缓存：直接删除vcs/目录下的内容通常是安全的，因为Composer会在需要时自动重新克隆。
• 谨慎对待repo/目录：尤其是repo/packagist.org/，这是核心的包索引缓存。删除它会导致首次更新操作显著变慢，非必要不建议清理。
• CI/CD流程中的策略：在持续集成环境中，缓存本应被复用以加速构建。盲目添加composer clear-cache步骤反而会降低效率，除非遇到了确切的缓存一致性问题。

镜像源切换后还从旧地址拉包？先清 repo/

这是一个经典问题：你已经把全局镜像切换到了阿里云或其他源（例如执行了composer config -g repo.packagist https://mirrors.aliyun.com/composer/），但Composer仍然报错“Could not find package”。

问题大概率出在repo/目录里残留的旧元数据上。Composer可能还在引用旧的索引信息。这时候，执行composer clear-cache（主要是清理repo/子目录）就是必须的操作，否则新配置无法完全生效。

还有一个容易被忽略的细节：有些团队会将Composer缓存目录设置到NFS共享存储或自建的镜像目录中。请注意，clear-cache命令只会清理composer config --global cache-dir所指向的那个默认或显式配置的路径，它不会去扫描系统里其他可能存在的缓存位置。如果你的缓存机制比较复杂，可能需要手动检查并清理这些特殊路径。