如何清理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的“重灾区”。
