Composer无更新后自动清理旧缓存的内置功能，缓存默认存于~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\cache（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%\Composer\cache
你可以用这条命令验证当前缓存路径和大小：
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）组合最实用。
