composer clear-cache 清除 Composer 本地缓存（files/repo/vcs），但不碰项目目录、vendor、composer.json、系统配置、CI共享缓存、镜像CDN及插件临时文件。
composer clear-cache 到底清什么，哪些东西它动不了
直接说结论：composer clear-cache 会清掉 Composer 自己维护的全部本地缓存，包括 ~/.composer/cache/files/（下载的 zip/tar 包）、cache/repo/（包元数据快照）、cache/vcs/（Git 克隆的裸仓库），但不会碰你的项目目录、vendor、composer.json 或系统级配置。
常见误解是“清了缓存就能装上新版本”——其实不是。如果你改了 composer.json 却没删 composer.lock 和 vendor，Composer 仍会按旧锁文件复用缓存里的老包，这时清缓存根本没用。
- 它不清理 CI 环境中挂载的共享缓存卷（比如 GitHub Actions 的
actions/cache） - 它不刷新镜像源服务器上的 CDN 缓存（比如阿里云镜像的响应可能被代理层缓存了）
- 它不处理某些插件（如
hirak/prestissimo）绕过标准逻辑产生的临时文件
什么时候必须清，什么时候清了也白清
遇到这些情况，composer clear-cache 是第一反应，大概率有效：
-
Could not parse version或Failed to download package，但网络正常 - 明明发布了 v2.3.0，
composer require vendor/pkg却只给到 v2.2.1 - 报错含
corrupted .zip file、checksum mismatch、invalid package archive
但下面这些场景，清缓存只是浪费时间：
- 刚执行过
composer update，但composer.lock没提交，换机器拉代码后装不上——问题在锁文件没同步，不是缓存 - 用了私有 Packagist 镜像，但镜像本身没同步上游更新——清本地没用，得查镜像状态
- CI 构建失败，错误是
file could not be downloaded: failed to open stream—— 可能是缓存损坏，但也可能是构建机 DNS 或 TLS 证书异常
手动删缓存：什么能删，什么别碰
如果 composer clear-cache 报错或卡住，或者你想精准控制（比如只清老 zip 节省磁盘），就得手动进目录操作。先查路径：composer config cache-dir。
缓存目录结构分三层，安全操作建议如下：
-
cache/files/：存所有下载过的 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明显变慢，不建议动
Windows 用户路径通常是 %APPDATA%\Composer\cache，macOS/Linux 是 ~/.composer/cache。
CI/CD 和 Docker 里要不要清缓存
不该无脑清。CI 环境靠复用 ~/.composer/cache 加速安装，composer clear-cache 会让每次构建都重新下载，拖慢流水线。
更合理的做法是：
- 在脚本开头加
composer config -g cache-dir /tmp/composer-cache，把缓存指向临时路径，容器销毁即清理 - 或直接用
composer install --no-cache，跳过缓存读写（适合极简构建） - 只有确认缓存损坏（比如报 checksum 错误且重试多次失败）才针对性
rm -rf ~/.composer/cache
缓存不是垃圾，是 Composer 的性能杠杆；乱清不如看清它在哪、被谁用、坏了怎么换。
