直接运行 composer clear-cache 即可安全清缓存，它只清理缓存目录，不删 vendor/、composer.lock 或项目配置；但若装不到新版本，因 composer.lock 会强制复现旧依赖树，需删 lock 文件后执行 install 或 update。
直接运行 composer clear-cache 就行，它只动缓存目录，不删 vendor/、composer.lock 或项目配置，安全且官方推荐。
先说几个关键点。很多开发者刚接触 Composer 时，一遇到依赖问题就习惯性清缓存，但清完之后发现新版包还是装不上，问题出在哪儿？
为什么有时候清了缓存还是装不到新版本？
玄机就在于 composer.lock 这个文件。它就像一张“旧时代的海图”，强制复现着旧的依赖树。缓存清得再干净，一执行 composer install，系统还是会按 lock 文件里的版本号去还原，跟缓存压根没关系。
- 想拉最新版：先删
composer.lock，再跑composer install或composer update - 只想更新某个包：
composer update vendor/package-name，避免全量重算 - 怀疑 lock 文件被意外改坏：
composer validate检查格式合法性
CI/CD 里执行 clear-cache 必须加 --no-interaction
这一点在自动化流水线里特别容易踩坑。默认的 composer clear-cache 在非交互环境（如 GitHub Actions、GitLab CI）会卡住，因为它内部可能尝试确认操作，但没人能给它一个“是”的回复。
- 正确写法：
composer clear-cache --no-interaction - 更彻底的 CI 清理组合：
— 先清全局缓存：composer clear-cache --no-interaction
— 再删整个vendor：rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows）
— 最后重装：composer install --no-interaction --prefer-dist - 别依赖
post-install-cmd脚本——CI 通常用--no-scripts跳过所有脚本
手动删缓存子目录前先看清楚路径和用途
缓存目录下有三个关键子目录，各自负责不同的缓存内容，误删可能影响后续体验。先说清楚它们的分工，再动手不迟。
files/：最占空间，可放心删旧包，比如用find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete清 90 天前的vcs/：切分支/换源频繁时容易积攒废弃目录，rm -rf ~/.composer/cache/vcs/*安全，下次需要自动重建repo/packagist.org/：核心索引缓存，删了会导致首次composer update明显变慢，不建议动- 执行前先确认 Composer 进程已退出，否则可能删到一半被写入，报
Corrupted cache file
真正容易被忽略的是：私有仓库配置（比如 repositories 在 composer.json 或全局 config 里）会让清完缓存后的首次请求变慢——不是 bug，是设计使然，元数据必须重新 fetch。
