Composer clear-cache如何释放_Composer磁盘空间优化思路

先直接说几个关键点：composer clear-cache 确实能清理几百 MB 到 1.5 GB 的缓存，但真正让人头疼的“大胃王”——vcs/ 目录，它默认是不碰的。这个目录里存放的是 Git 克隆缓存，一个 Lara vel 或 Symfony 的完整裸仓库就常占 300–800 MB，这才是磁盘空间告警的幕后黑手。

怎么确认缓存真占地方、路径对不对？

别靠猜默认路径，composer config --global cache-dir 才是唯一可信来源。公司镜像、自定义的 COMPOSER_HOME 或 COMPOSER_CACHE_DIR，都可能把缓存挪到非预期位置，一不留神就绕过了常规清理。

• Linux/macOS 上，推荐直接跑 du -sh $(composer config --global cache-dir) 看真实体积。如果输出只有 4.0K 或提示 No cache files to delete，说明缓存基本空了，清也白清。
• Windows 用户，直接在资源管理器地址栏贴 %APPDATA%\Composer\Cache，右键“属性”看大小。若不到 200 MB，基本可以排除它是磁盘告警的主因。
• 特别值得单独查一下 du -sh ~/.composer/cache/vcs/，这个子目录常常独占了总缓存 70% 以上，是真正的“重灾区”。

为什么 composer clear-cache 后还是满？重点盯住 vcs/

composer clear-cache 默认只清理 files/、repo/、http/ 这几个目录，vcs/ 是被跳过的。这不是 bug，而是设计如此。但问题在于，它让大量 Git 裸仓库长期滞留，每个都带着完整的 .git 目录，文件数动辄上万，在 WSL 或 macOS 的 APFS 文件系统上，极易耗尽 inodes，导致磁盘明明还有空间，却提示“磁盘已满”。

• Linux/macOS：清完缓存后，建议立刻补一句 rm -rf ~/.composer/cache/vcs/。注意尾部斜杠，vcs/ 比 vcs 更安全，能避免误删同名文件的风险。
• Windows：用 CMD 运行 rd /s /q "%APPDATA%\Composer\Cache\vcs"。PowerShell 可能因执行策略失败，别硬扛，换个工具就好。
• 对于 CI 环境或小磁盘机器，建议直接永久禁用：composer config --global cache-vcs false。这样后续所有 Git 包都会强制走 --prefer-dist，不再缓存裸仓库，一劳永逸。

清完为啥装包变慢？这不是故障，是代价

缓存清空后，首次 composer install 或 composer update 必然变慢，因为要重新下载所有 .zip 包和 packages.json。这不是命令出错，而是设计使然，需要理解其中的原理：

• repo/packagist.org/ 缺失后，每次都要发起 HTTP 请求拉取元数据，你会明显卡在 Loading composer repositories 这一步。
• files/ 缺失后，所有 dist 包都要重新下载，特别是那些包含大资产的包，比如 lara vel/ui，感受最明显。
• 所以，别频繁清理。每月一次，或者仅在 df -h 报警时执行就够了。日常维护优先考虑 composer self-update，新版对缓存压缩更聪明，也更省空间。

最后必须提醒一句：真正吃 C 盘的，往往不是缓存本身，而是项目里反复 composer install 留下的旧 vendor/ 目录、没删干净的 node_modules/，或者 Composer 在系统临时目录（sys_get_temp_dir()）解压 ZIP 时爆掉的碎片文件——这些，clear-cache 一概不管。