composer clear-cache 会清掉哪些东西
它只清理 Composer 自己的本地缓存目录（通常是 ~/.composer/cache），包括：已下载的 zip 包、解压后的 dist 包、composer.lock 衍生的元数据缓存、远程包信息（如 packagist.org 的 JSON 响应快照）。不会碰你的项目目录、vendor、composer.json 或系统级配置。
为什么 composer clear-cache 有时没效果
常见原因有三个：
- 你改了
composer.json但没删vendor和composer.lock，Composer 仍按旧锁文件复用缓存包 —— 此时清缓存根本没用，得先rm -rf vendor composer.lock再composer install - 用了镜像源（比如阿里云、腾讯云），镜像本身有 CDN 缓存或代理层缓存，
clear-cache只清本地，不刷新镜像服务器上的响应 - 某些插件（如
hirak/prestissimo）会绕过默认下载逻辑，它们的临时文件不在标准缓存路径里，clear-cache不覆盖
删冗余缓存：手动清理更准，但得认路
Composer 缓存目录结构是分层的：cache/files/ 存 zip 包，cache/repo/ 存元数据，cache/vcs/ 存 git clone 的裸仓库。真正“冗余”的往往是：
-
cache/files/下大量老版本 zip（比如monolog/monolog/1.25.0.zip和1.26.1.zip都留着）—— 可用find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete清 90 天前的 -
cache/vcs/里残留的已废弃包 git 目录（尤其当你频繁切分支或换源时）—— 直接rm -rf ~/.composer/cache/vcs/*安全，下次需要时自动重建 - 注意：别动
cache/repo/下的packagist.org/，那是核心索引，删了首次composer update会明显变慢
CI/CD 或 Docker 构建中该不该清缓存
不该无脑清。CI 环境通常挂载缓存卷（如 GitHub Actions 的 actions/cache），目标是复用 ~/.composer/cache 加速安装。这时候执行 composer clear-cache 反而让每次构建都重新下载，拖慢流水线。
真要“清理冗余”，推荐做法是：
- 在 CI 脚本开头加
composer config -g cache-dir /tmp/composer-cache，把缓存指向临时路径，自然随容器销毁 - 或者用
composer install --no-cache，跳过缓存写入（但不读也不写，适合极简构建） - 如果发现某次构建因缓存损坏失败（比如报
file could not be downloaded: failed to open stream），再针对性rm -rf ~/.composer/cache并重试
缓存不是垃圾，是 Composer 的性能杠杆；乱清不如看清它在哪、被谁用、坏了怎么换。
