执行 composer clear-cache 后磁盘空间未明显减少，是因为该命令只清理 ~/.composer/cache 下的缓存（如 ZIP 包、元数据），不触及 vendor/ 目录；若缓存本身较小（如不足 200MB），则释放空间有限。
composer clear-cache 为什么清完没释放空间
执行 composer clear-cache 后磁盘空间没明显减少，大概率是因为你真正想删的不是缓存，而是 vendor/ 目录。缓存默认在 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows），而 vendor/ 是项目级依赖副本，clear-cache 完全不碰它。
先确认缓存真实大小再动手：
- 查路径：
composer config --global cache-dir - 看体积（Linux/macOS）：
du -sh $(composer config --global cache-dir) - Windows 用户直接打开资源管理器，粘贴
%APPDATA%\Composer\Cache查“属性”
如果缓存不到 200MB，别指望靠它腾出几 GB；超过 1.5GB 才值得清理。
只删旧 ZIP 包，不伤元数据和 Git 缓存
composer clear-cache 是全量操作，但多数人只想甩掉积压的旧版 dist 包（比如 monolog/monolog 的 1.x 系列 ZIP），又不想让下次 composer update 卡在拉 packages.json 上。
安全做法是手动进 files/ 子目录清理：
- 删 90 天前的 ZIP：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 删所有 ZIP（保留目录结构）：
rm -rf ~/.composer/cache/files/* - 别动
repo/packagist.org/：这是核心元数据快照，删了首次 update 会变慢 - 可放心清
vcs/：rm -rf ~/.composer/cache/vcs/*，下次需要自动重建
手删前确保没有 composer install 或 update 进程在后台跑，否则可能触发 Corrupted cache file 报错。
CI/CD 里清缓存必须加 --no-interaction
GitHub Actions、GitLab CI 等非交互环境执行 composer clear-cache 会卡住——它内部默认尝试交互确认。
正确写法只有这一种：
composer clear-cache --no-interaction- 更彻底的 CI 组合：
composer clear-cache --no-interaction && rm -rf vendor && composer install --no-interaction --prefer-dist
注意：别依赖 post-install-cmd 脚本，CI 通常用 --no-scripts 跳过所有钩子；也别假设缓存路径是默认值，某些 Docker 镜像或公司规范会通过 COMPOSER_CACHE_DIR 指向挂载卷，clear-cache 只清那个路径，不会遍历。
清完装包变慢不是 bug，是设计如此
清空 repo/ 后，首次 composer update 必须重新 HTTP 请求 packagist.org 或镜像源拉 packages.json；清空 files/ 后，所有 ZIP 都得重下——尤其含大前端资产的包（如 laravel/ui）会明显卡顿。
这不是命令出错，是 Composer 的缓存机制决定的：
-
repo/缺失 → 每次都要 fetch 元数据 -
files/缺失 → 所有 dist 包重下载，不走本地缓存 - 私有仓库配置存在时，首次恢复还会额外拉取认证后的私有索引
真正容易被忽略的是：缓存清理解决不了 composer.lock 锁定旧版本的问题。清得再干净，composer install 仍按 lock 文件还原——想升版，得先删 lock 或运行 composer update vendor/package。
