答案是inode耗尽而非磁盘块用光；需先用df -i确认缓存分区inode使用率是否≥95%，再通过composer config --global cache-dir定位路径，优先清理vcs/目录及系统临时文件，避免直接rm -rf后瞬间重建。
不是缓存占满磁盘，就是它了——但大概率是 inode 耗尽，不是磁盘块用光。
df -h 显示还有空间，却报 disk full？先查 inode
Composer 缓存（尤其是 ~/.composer/cache/files/ 和 ~/.composer/cache/vcs/）会生成数万个小文件，每个都占一个 inode。APFS（macOS）、某些 Linux 发行版或 NFS 挂载点极易触发 inode 耗尽，df -h 看起来还有 20GB，df -i 却显示 Use% 是 99%。
- 立刻运行：
df -i，重点关注缓存所在分区的 Use% - 确认缓存路径：
composer config --global cache-dir - 如果 Use% ≥ 95%，别删文件，先切路径再清——否则
rm -rf后 composer 会瞬间重建大量小文件，再次打满
composer clear-cache 执行后空间没变？你可能清错了地方
composer clear-cache 只清理 cache-dir 指向的目录，不碰 vendor/、不扫 NFS 挂载点、也不理系统临时目录。很多人清完发现磁盘没松动，是因为：
- 真正的大头是
vendor/（一个 Laravel 项目常超 300MB），而缓存可能才 42MB - 公司镜像把缓存重定向到了
/mnt/nfs/composer-cache，但你在本地删~/.composer/cache - PHP 的临时目录（
sys_get_temp_dir()）堆积了大量composer_*.zip和php*.phar，Windows 在C:\Users\xxx\AppData\Local\Temp，Linux/macOS 常在/tmp
查真实缓存大小：Linux/macOS 运行 du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器，粘贴 %APPDATA%\Composer\Cache 查属性。
想彻底释放空间？vcs/ 目录才是隐藏杀手
~/.composer/cache/vcs/ 存的是 Git 裸仓库（完整 .git），单个包克隆就吃掉 300–800MB，且长期滞留、几乎不复用。composer clear-cache 默认不删它——这是最常被忽略的膨胀源。
- 安全清理方式：
rm -rf $(composer config --global cache-dir)/vcs/*（确保没有composer install或update正在运行） - 不想下次又爆？关掉 dist 缓存：
composer config --global cache-files-dir false（注意填字符串false，不是布尔值） - 顺手把临时目录也扫一遍：
find /tmp -name "composer_*" -mmin +60 -delete（Linux/macOS）或手动清%TEMP%（Windows）
清完还是卡、报错、装旧包？这不是缓存问题
缓存只是加速层，不是决策源头。清完还出问题，说明根源不在这儿：
- 装旧包？看
composer.lock锁定的版本，或镜像源元数据未更新（TTL 通常 24 小时） - 报
file could not be downloaded？检查网络、代理、composer config repo.packagist是否生效 - 执行
clear-cache卡住不动？可能是某个损坏的.zip文件反复校验失败，加--no-interaction跳过交互，或用lsof +D ~/.composer/cache（macOS/Linux）查占用进程
vcs/ 目录和系统临时目录这两个地方，多数人清理时根本不会想到去看一眼——它们不显眼，但吃空间最狠，也最容易被误判为“缓存已清，问题还在”。
