Composer缓存清理：你以为的清空，可能只是“重启”
遇到依赖问题，很多人的第一反应是执行 composer clear-cache，仿佛这是个万能的重置按钮。但结果往往令人困惑：缓存清了，composer install 之后，装上的却还是旧版本。别急着怀疑人生，这并非命令失效，而是设计本就如此。简单来说，这个命令只清理本地的下载缓存，绝不会动你的项目文件，包括 vendor/ 目录和锁定的版本清单 composer.lock。
composer clear-cache 到底删了哪几样东西？
这个命令的操作范围非常明确，只针对 Composer 的全局缓存目录。这个目录的路径可以通过 composer config --global cache-dir 查看（Linux/macOS 默认在 ~/.composer/cache，Windows 则在 %APPDATA%\Composer\Cache）。它清理的是下面这三个子目录：
files/：所有已下载的依赖包压缩文件，比如.zip、.tar包。repo/：从远程仓库（如 packagist.org）拉取的元数据快照，例如packages.json。vcs/：从 Git 仓库安装包时，克隆下来的裸仓库缓存，用于后续复用。
那么，哪些东西它绝对不碰呢？你的项目核心文件——vendor/、composer.json、composer.lock——都是安全的。此外，PHP 的 OPcache、CI/CD 构建中挂载的共享缓存卷、镜像服务器的 CDN 缓存，以及某些插件（例如 hirak/prestissimo）生成的临时文件，也都不会受到影响。
为什么缓存清了，还是装不到新版？
这个问题最常见的根源，其实跟缓存关系不大，而在于版本锁定或元数据更新延迟。可以逐一排查：
composer.lock文件存在：只要这个文件在，执行composer install就一定会严格按照里面记录的版本和依赖树来安装，跟缓存清没清毫无关系。- 镜像源有 CDN 缓存：如果你使用了阿里云、腾讯云等镜像，
clear-cache只清本地，无法刷新镜像服务器上的packages.json等元数据。 - 私有包只更新了标签：对于私有 Git 仓库，如果只打了新 tag 但没有新的 commit，Composer 可能会直接复用本地已解压的缓存，根本不会去远程检查。这种情况下，清理缓存才有效。
- 元数据 TTL 未过期：即使清空了
repo/目录，首次执行update时，如果从远程拉取的元数据快照还在有效期内，你拿到的可能依然是旧数据。
真想强制升级到最新可用版本？正确的姿势是：先删除 composer.lock 文件，再执行 composer update。或者，使用 composer install --no-cache 来跳过本次安装的缓存读写（注意，这个参数不是用来清缓存的）。
手动精准清理，比无脑全清更实用
Composer 没有提供按包名、时间或大小筛选缓存的内置命令。真想精细化管理、节省磁盘空间，就得手动进入缓存目录操作：
- 清理老旧压缩包：例如，删除90天前的 zip 包：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 清理 Git 仓库缓存：
rm -rf ~/.composer/cache/vcs/*通常是安全的，下次需要时会自动重新克隆。 - 谨慎对待核心索引：别轻易删除
repo/packagist.org/里的内容，这是包索引的核心数据，删了会导致首次composer update明显变慢。 - 确保进程已结束：手动删除前，确认没有 Composer 进程在后台运行，否则可能引发
Corrupted cache file之类的报错。
还有一个容易被忽略的点：有些团队会将缓存目录挂载到 NFS 或自建的镜像目录。默认的 clear-cache 命令只会清理全局配置指向的那个路径，不会遍历所有可能的缓存位置。
在 CI/CD 中，无脑清理缓存反而会拖慢构建
缓存的核心价值在于复用，而不是每次推倒重来。在持续集成环境中，需要更有策略：
- 利用平台缓存机制：像 GitHub Actions 这类平台，推荐使用
actions/cache来挂载~/.composer/cache。每次构建都清缓存，等于放弃了加速优势。 - 实现“干净构建”：如果确实需要每次都是全新环境，更稳妥的做法是临时修改缓存路径：
composer config -g cache-dir /tmp/composer-cache，让缓存随容器销毁而自动清理。 - 针对性清理：只有遇到明确的缓存损坏错误，如
Failed to extract或file could not be downloaded，才有必要针对性执行rm -rf ~/.composer/cache。 - 升级 Composer 本身：如果频繁遇到缓存问题，不如定期
composer self-update。新版本往往在缓存的压缩和复用策略上更加智能。
说到底，缓存不是垃圾，而是 Composer 提升性能的重要杠杆。与其乱清一气，不如先看清它在哪里、被谁使用、以及真正出问题时该如何有效替换。
