composer clear-cache 能安全清理 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的 files/、repo/、installers/ 子目录，但默认跳过占空间最大的 vcs/ 目录；需先用 composer config --global cache-dir 确认真实路径，再通过 du -sh（Linux/macOS）或资源管理器“属性”（Windows）核查大小，超1.5 GB且半年未用才建议清理。
composer clear-cache 能清掉 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）里的 files/、repo/、installers/，但默认跳过真正吃空间的 vcs/ 目录——不手动补一刀，磁盘空间基本白腾。
怎么确认缓存路径和真实占用大小
别凭印象删。先查 Composer 实际用的路径，再看它到底占了多少：
- 运行
composer config --global cache-dir，输出就是真实路径（可能被COMPOSER_CACHE_DIR环境变量或公司镜像覆盖） - Linux/macOS 下立刻接：
du -sh $(composer config --global cache-dir) - Windows 用户把
%APPDATA%\Composer\Cache粘进资源管理器地址栏 → 右键“属性” - 不到 200 MB 基本不用管；超 1.5 GB 且你半年没碰某些老项目，才值得动手
为什么 composer clear-cache 清完空间没变
最常见三个原因：
- 你真正想删的是
vendor/目录——它不属于 Composer 缓存体系，一个中等 Laravel 项目常占 300–800 MB -
vcs/目录被默认跳过，但单个 Git 裸仓库就吃掉 300–800 MB，还耗尽 inode；必须手动删：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 临时目录
sys_get_temp_dir()下堆着大量composer_*.zip、php*.phar，clear-cache完全不碰这里
CI/CD 或无交互环境里卡住怎么办
GitHub Actions、GitLab CI 等环境里，composer clear-cache 默认会等待交互确认，直接 hang 住：
- 必须加
--no-interaction：避免卡在提示 - 建议先加
--dry-run预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 如果仍卡住，说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或handle.exe -p php.exe（Windows，需 Sysinternals 工具）
手动清理比 clear-cache 更危险也更精准
官方命令会跳过正在被占用的文件，而 rm -rf 不判断——删到一半被写入，后续可能报 Corrupted cache file：
- 只删下载过的原始包（省最多空间）：
rm -rf ~/.composer/cache/files/* - 只清元数据（解决“装不到新版包”类问题）：
rm -rf ~/.composer/cache/repo/* - 只清 Git 克隆缓存（安全，下次需要自动重建）：
rm -rf ~/.composer/cache/vcs/* - 手删前务必确认没有
composer install或update进程在后台跑
真正容易被忽略的是 vcs/ 目录——它不参与 clear-cache 默认流程，却常年静默吞噬数百 MB 空间和海量 inodes，尤其在 WSL 或 macOS APFS 下，df -i 显示 inode 耗尽时，clear-cache 本身毫无作用。
