composer clear-cache 是最安全的缓存清理方式，仅删除 Composer 缓存目录内容，不影响 vendor、composer.lock 和项目配置，官方推荐为第一步操作。
composer clear-cache 是最安全的删除方式
它只删 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache\（Windows）里的内容，不影响 vendor/、composer.lock 或项目配置。这是官方推荐的第一步，不是“可能有用”，而是“该用就用”。
- 执行
composer clear-cache后会显示清理了多少 MB 和路径，比如：Clearing cache (124.5 MiB) - 等价命令还有
composer cache-clear和composer clearcache，三者完全一致 - 加
--dry-run参数可预览：运行composer clear-cache --dry-run看清哪些目录会被动，再决定是否真删
手动删缓存前必须确认三件事
直接 rm -rf ~/.composer/cache 或 Windows 下删 %APPDATA%\Composer\Cache 很快，但容易出问题——不是命令错了，是时机不对。
-
composer install或composer update进程必须已退出，否则可能删到一半被写入，后续报Corrupted cache file - 检查是否启用了缓存生命周期控制：
composer config --global --list | grep -E "(cache-files-ttl|cache-files-maxsize)"。盲目清空会让下次安装变慢，尤其启用了cache-files-maxsize时，系统本会自动淘汰旧包 - 如果你用的是阿里云、腾讯云等国内镜像源，清完首次
install会重新下载所有.zip，网络不稳可能卡在某个大包（如laravel/ui）上
清完缓存还装错版本？那不是缓存的问题
很多人清完缓存发现 composer install 还是旧版，以为命令失效。其实 clear-cache 不影响版本决策逻辑——它只清下载物，不改约束规则。
- 真正锁定版本的是
composer.lock。缓存清了，lock 文件还在，install就照旧装 - 想拉新版本，得先删
composer.lock，再跑composer install；或直接composer update vendor/package-name - 如果刚切了镜像源但还是 404，可能是
repo/子目录里残留了旧源的元数据，这时clear-cache有效；但若composer.json里repositories指向了一个已下线的私有源，删缓存也没用
CI/CD 里别乱加 clear-cache
Docker 构建或 GitHub Actions 默认是干净环境，~/.composer/cache 基本为空。加了 clear-cache 反而拖慢构建，因为每次都要重下所有 .zip 和元数据。
- CI 中更有效的做法是：用
--no-interaction --no-progress --prefer-dist减少输出和体积 - 如果真要模拟“从零开始”，应该组合操作：
rm -rf vendor composer.lock+composer install --no-cache，而不是单靠清缓存 - 长期运行的 CI 机器（比如 Jenkins slave）才需要定期
clear-cache，建议每月一次或磁盘使用超 80% 时触发
repo/、files/、archives/）和行为细节，比如元数据 TTL、镜像同步延迟、私有源认证缓存位置，这些才是真正影响“删了为什么还不灵”的关键点——它们不会出现在 clear-cache 的提示里，得自己查。 
