可以删，但必须用composer clear-cache或精准手动删子目录，否则会破坏缓存索引、引发Corrupted cache file错误；它安全清理files/、repo/、vcs/子目录，不碰vendor/、composer.lock等项目文件，且默认跳过占空间最大的vcs/目录——需手动清或禁用cache.vcs。
可以删，但不能直接 rm -rf 整个目录——必须用 composer clear-cache 或精准手动删子目录，否则可能破坏缓存索引、引发 Corrupted cache file 错误。
确认当前缓存路径再动手
很多人删了 ~/.composer/cache 却发现空间没变，是因为 Composer 实际用的路径早被 COMPOSER_CACHE_DIR 或公司镜像覆盖。不查真实路径就删，大概率删错地方。
- 查真实路径：
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 清什么、不碰什么
这个命令是安全底线：它只动 files/（ZIP 包）、repo/（元数据快照）、vcs/（Git 裸仓库）三个子目录，绝不会碰 vendor/、composer.lock、composer.json 或任何项目文件。
- 清完后首次
composer install会慢一点——因为要重下 ZIP、重解压，属正常现象 - 如果执行后没输出
Clearing cache (X.X GiB)，而是报Cache directory does not exist，说明路径异常或权限不对 - CI/CD 中必须加
--no-interaction，否则默认卡在交互确认上
为什么 clear-cache 后空间没变化？重点盯 vcs/
vcs/ 目录才是磁盘和 inode 的双料杀手：单个 Git 裸仓库（含完整 .git）就能占 300–800 MB，还带几万个文件。而 composer clear-cache 默认跳过它。
- 确认占用：
du -sh $(composer config --global cache-dir)/vcs（Linux/macOS）或 Windows 对应路径右键属性 - 手动清：
rm -rf ~/.composer/cache/vcs/*（注意末尾/*，别漏掉） - 一劳永逸：
composer config --global cache.vcs false，后续所有包强制走--prefer-dist - 别删
repo/packagist.org/太勤——这是核心索引，删了会导致首次composer update明显变慢
想精准清理？没有内置命令，只能手动筛
composer clear-cache 是全量操作，不支持按包名、时间、大小筛选。所谓“精准”，得靠你自己进目录认路，但必须确保没 composer install 或 update 进程在后台跑。
- 只清老 ZIP（90 天前）：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 只清废弃 Git 缓存：
rm -rf ~/.composer/cache/vcs/*（安全，下次需要自动重建） - 权限出问题时（比如曾用
sudo composer install）：sudo chown -R $USER:$USER ~/.composer/cache - CI 构建机上多个 job 共享缓存目录？必须加锁，否则并发
clear-cache和install会冲突报错
最常被忽略的是临时目录：sys_get_temp_dir()（Windows 是 C:\Users\用户名\AppData\Local\Temp，Linux/macOS 是 /tmp）里堆积的 composer_*.zip 和 php*.phar 文件，尤其在频繁 create-project 的场景下，这块也得定期扫。
