composer clear-cache 能安全清掉全局缓存中的 files/、repo/、vcs/ 子目录，但不触碰 vendor/、composer.lock 或项目文件；需先用 composer config --global cache-dir 确认真实路径，再通过 du -sh（Linux/macOS）或资源管理器属性（Windows）检查占用，超 1.5 GB 且半年未用才值得清理；vcs/ 目录默认被跳过，单个 Git 裸仓库占 300–800 MB 并耗尽 inode，须手动删除或禁用 cache.vcs。
composer clear-cache 能安全清掉全局缓存里的 files/、repo/、vcs/ 子目录，但不会动 vendor/、composer.lock 或项目文件——这是最常用也最不容易出错的方式。
怎么确认缓存路径和真实占用？别删错地方
很多人一看到磁盘告警就跑 composer clear-cache，结果空间没变——因为缓存路径可能早被 COMPOSER_CACHE_DIR 或公司镜像覆盖，~/.composer/cache 根本不是 Composer 当前用的目录。
- 先查真实路径：
composer config --global cache-dir - Linux/macOS 看大小：
du -sh $(composer config --global cache-dir) - Windows 直接在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache→ 右键“属性” - 不到 200 MB 基本不用管；超过 1.5 GB 且半年没碰老项目，才值得动手
为什么 composer clear-cache 清完空间没变化？
最常见原因是：你真正想删的是项目里的 vendor/，不是全局缓存。一个中等 Laravel 项目 vendor/ 常超 300 MB，而缓存可能只有 42 MB。
-
vcs/目录才是磁盘和 inode 杀手：单个 Git 裸仓库（含.git）就能吃掉 300–800 MB，且clear-cache默认跳过它 - 要清它，得手动：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 禁用它更省事：
composer config --global cache.vcs false，后续所有 Git 包强制走--prefer-dist
CI/CD 或无交互终端里卡住？加这两个参数
在 GitHub Actions、GitLab CI 里，composer clear-cache 默认会等交互确认，直接 hang 住。
- 必须加
--no-interaction：避免卡在提示 - 建议加
--dry-run先预检：输出将清理的路径，确认是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 命令组合示例：
composer clear-cache --no-interaction --dry-run→ 确认无误后再去掉--dry-run - 如果仍卡住，说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或handle.exe -p php.exe（Windows，需 Sysinternals 工具）
手动删比 clear-cache 更“精准”，但也更危险
composer clear-cache 是全量操作，没有按包名、时间、大小筛选的内置选项。所谓“精准”，只能靠你自己进目录判断：
- 只删老 ZIP 包（90 天前）：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 只清元数据（解决“装不到新版包”类问题）：
rm -rf ~/.composer/cache/repo/* - 只清 Git 克隆缓存：
rm -rf ~/.composer/cache/vcs/* - 手删前务必确认没有
composer install或update进程在后台跑，否则可能触发Corrupted cache file报错
真正容易被忽略的是：某些团队把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 composer config --global cache-dir 指向的那个路径，不会遍历所有可能位置。
