如何让Composer在更新包之后自动清除旧的缓存文件？ (缓存管理)

composer无更新后自动清理旧缓存的内置功能，缓存默认存于~/.composer/cache（linux/macOS）或%appDATA%Composercache（windows），需手动执行composer clear-cache或通过post-update-cmd脚本按lock文件智能清理files/下未引用的旧包归档。

Composer 本身没有“更新后自动清理旧缓存”的内置开关，composer update 或 composer install 执行时不会主动删除历史缓存包（比如旧版本的 .zip 或 .tar.gz 归档）。缓存文件堆积在 COMPOSER_HOME/cache 下，长期不清理会占用磁盘空间，且可能干扰调试（例如误用本地缓存的损坏包）。

Composer 缓存目录在哪？怎么确认它正在被使用

Composer 默认使用环境变量 COMPOSER_HOME 指定缓存根目录；未设置时 fallback 到：
– Linux/macOS：~/.composer/cache
– Windows：%APPDATA%Composercache

你可以用这条命令验证当前缓存路径和大小：

composer config --global cache-dir du -sh $(composer config --global cache-dir)

注意：cache-dir 是缓存根目录，其下有 files/（下载的归档）、repo/（包元数据）、vcs/（git 克隆副本）等子目录。真正占空间的通常是 files/ 里的旧版本压缩包。

手动清理缓存的可靠方式

Composer 提供了两个关键命令，但用途不同，容易混淆：

• composer clear-cache：清空整个缓存目录（files/、repo/、vcs/ 全删），下次安装会重新下载所有依赖——适合解决缓存损坏、网络代理污染等问题，但不区分“新旧”，也非“更新后自动触发”
• composer archive：不是清理命令，是打包命令，别误用

如果你只想删掉「已不再被任何 composer.lock 引用的旧包归档」，Composer 没有原生支持。必须靠外部脚本或 CI 工具配合判断。

用 post-update-cmd 脚本实现“更新后自动清理旧包”

Composer 的 scripts 支持 post-update-cmd 钩子，在 update 完成后执行任意命令。我们可以写一个简单脚本，只清理那些不在当前 composer.lock 中出现的包归档。

步骤如下：

• 在项目根目录的 composer.json 中添加：

"scripts": {   "post-update-cmd": [     "php -r "$lock = json_decode(file_get_contents('composer.lock'), true); $pkgs = []; foreach (($lock['packages'] ?? []) as $p) { $pkgs[] = $p['name'] . '-' . $p['version']; } $cache = rtrim(exec('composer config --global cache-dir'), '/'); $files = glob("$cache/files/*/*"); foreach ($files as $f) { if (is_file($f) && !in_array(basename(dirname($f)), $pkgs)) { @unlink($f); } } echo 'Cleaned unused package archives.\n';""   ] }

• 这个脚本逻辑是：解析 composer.lock → 提取所有 name-version 组合 → 遍历 cache/files/ 下每个子目录 → 若该子目录名不在 lock 文件列表中，则删除其下所有文件
• 它不会动 repo/ 或 vcs/，避免影响元数据刷新和 Git 操作
• 缺点：不处理带 +dist 或 -dev 后缀的版本号差异（如 v1.2.3+git123），若你大量使用 dev-master 或 dist 覆盖，需扩展匹配逻辑

CI/CD 环境建议用更稳妥的方案

在 github Actions、gitlab CI 等场景中，每次作业都是干净环境，没必要保留缓存旧包。推荐做法是：

• 用 composer install --no-cache 完全跳过缓存（适合构建镜像）
• 或在 job 结尾加一步：composer clear-cache && echo 'Cache cleared'（简单粗暴，适合资源充足的 runner）
• 避免在 CI 中依赖 post-update-cmd 清理，因为 composer.lock 可能尚未提交，脚本判断不准

真正需要“智能清理”的场景，往往出现在本地开发机或共享构建服务器上——那里缓存长期存在，而开发者又不常手动运行 clear-cache。这时候，钩子脚本 + 定期 cron（如每周 find ~/.composer/cache/files -mtime +30 -delete）组合最实用。