如何清理Composer的缓存以释放磁盘空间

如何清理Composer的缓存以释放磁盘空间

直接执行 composer clear-cache 确实能安全释放空间，但别急着敲回车——先搞清楚它是不是真的占了大头、路径对不对、有没有被镜像配置悄悄挪了位置。

怎么查缓存占了多大、在哪儿

缓存路径这事儿，别靠猜。公司内网镜像或者个人配置都可能把它改到别处，所以 composer config --global cache-dir 才是唯一靠谱的查询方式。默认的 ~/.composer/cache 不一定对。

• Linux/macOS用户：运行 du -sh $(composer config --global cache-dir)，立马看到实际占用体积。
• Windows用户：打开资源管理器，把 %APPDATA%\Composer\Cache 粘贴到地址栏，右键查看“属性”。
• 如果发现体积还不到200MB，那基本可以排除它是磁盘告警的元凶。什么时候才值得动手？通常是缓存超过1.5GB，并且你确认有些老项目半年以上没碰了。

为什么 composer clear-cache 比手动删目录更安全

手动删除 ~/.composer/cache 目录看似痛快，实则暗藏风险，容易引发锁文件冲突或损坏缓存结构，在WSL或Windows环境下尤其常见。

那么官方的清理命令高明在哪儿？它有一套标准流程：先暂停写入锁，然后按顺序清空 repo/、files/、vcs/ 这些子目录，最后重置 cache.json。整个过程干净利落。

• 更重要的是，它很“懂事”——绝不会碰你的认证文件（auth.json）、个人配置（config.json），更不会影响项目本地的 vendor/ 目录或 composer.lock 文件。
• 命令执行完后，你会看到类似 Cleared cache for all packages (842 MiB) 的输出。括号里的数字就是实打实释放的空间，可不是估算值。

清完为啥装包变慢？这不是bug，是设计

缓存清空后，第一次运行 composer install 或 composer update 肯定会变慢，这完全正常。因为所有依赖包的 .zip 文件和元数据都得重新下载。

• repo/ 目录空了？那就意味着每次都要向镜像源发起HTTP请求，重新拉取庞大的 packages.json 文件。
• files/ 目录没了？所有通过dist方式分发的包都得重下一遍，像Lara vel UI这种包含前端资源的包，感受会特别明显。
• 给国内开发者的建议是：如果还没配置，最好提前把镜像切换到阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。这能显著提升下载速度。

想精准清理旧包而不是全删？只能手动筛

很遗憾，Composer目前没有提供 --only-unused 或 --before 2025 这类智能清理参数。所谓的“精准清理”，目前还得靠手动比对。

具体怎么做？这里有个笨办法但有效：

• 进入缓存的文件目录，通常是 ~/.composer/cache/files/。里面的子目录名一般是 vendor-name/version.zip 这样的格式。
• 然后，打开你各个项目的 composer.lock 文件，搜索 "name": "monolog/monolog" 这样的字段，找到其对应的 "version"。
• 最后，只删除那些不在任何现有项目 composer.lock 文件中间出现的zip包。注意，是删文件，别把整个包目录都删了。
• 至于 vcs/ 目录，倒是可以放心全清：rm -rf ~/.composer/cache/vcs/*。这里存放的是版本控制元数据，下次需要时会自动重建，非常安全。

话说回来，还有一个更隐蔽的“磁盘杀手”容易被忽略——inodes耗尽。尤其是在WSL或macOS的APFS文件系统下，df -hNo space left on device。这时候就该跑一下 df -i 命令，如果Use%接近100%，问题就出在文件数量太多上。而Composer的 vcs/ 目录里大量的小文件，往往是消耗inodes的“重灾区”。