composer磁盘空间不足主因是缓存和临时文件堆积导致inode耗尽，需先用df -h和df -i定位问题，再安全清缓存、禁用vcs缓存并清理临时目录。
磁盘空间不足不是 Composer 故意占地方，而是它默认缓存 ZIP 包、解压后源码、repo 元数据三类文件，长期不清理会同时吃掉磁盘空间和 inode——尤其在容器、CI 或 Windows 用户目录下，df -h 显示还有空间，df -i 却爆满，这才是真凶。
先确认是磁盘满还是 inode 满
报 No space left on device 且卡在 Downloading 阶段时，别急着删项目目录。先跑两行命令：
-
df -h看各挂载点使用率（重点看/tmp和缓存所在分区） -
df -i看 inode 使用率——如果Use%接近 100%，哪怕磁盘剩 20GB 也照样失败
Composer 缓存里每个包都建独立子目录（比如 ~/.composer/cache/files/monolog/monolog/1.27.0/），全是小文件，正是 inode 杀手。Windows 上 %APPDATA%\Composer\Cache\ 同样适用该判断逻辑。
清缓存前必须停掉所有 composer 进程
直接 rm -rf ~/.composer/cache 很危险：IDE 内嵌的 Composer 扫描、上一个 composer install 残留的锁文件、甚至未退出的 php /path/to/composer.phar 进程，都会导致删一半就报 file_put_contents(): No space left on device，甚至损坏缓存索引。
- 先查进程：
ps aux | grep composer（Linux/macOS）或tasklist | findstr composer（Windows） - 杀干净：
kill -9 $(pgrep -f "composer")或手动结束对应 PID - 再执行：
composer clear-cache——它会校验完整性、安全删除，并重建必要元数据
清完用 du -sh ~/.composer/cache 确认是否真空；若仍报错，说明有进程锁着文件，得重试 kill 步骤。
禁用 vcs/ 缓存能省最多空间且最安全
cache/vcs/ 子目录存放 Git 克隆的裸仓库，每个包一个仓库，动辄几百 MB + 成千上万个小文件，是 inode 和磁盘双料杀手。但它对绝大多数项目完全非必需——禁用后 Composer 会自动 fallback 到 --prefer-dist 流程（下载 ZIP 包）。
- 运行：
composer config --global cache.vcs false - 后续所有 Git 包强制走 dist 安装，无需额外参数
- 已存在的
vcs/目录可安全手动删：rm -rf ~/.composer/cache/vcs/（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows）
注意：cache/repo/ 别碰，删了会导致首次 composer update 卡很久；cache/files/ 和 cache/archives/ 可由 clear-cache 安全处理。
临时目录（sys_get_temp_dir）常被忽略但更致命
Composer 解压 ZIP、生成 autoloader、运行脚本时，重度依赖 PHP 的 sys_get_temp_dir() 返回路径。这个目录在 Windows 上通常是 C:\Users\用户名\AppData\Local\Temp，Linux/macOS 是 /tmp 或 $TMPDIR。
- 它容易堆积大量未清理的
composer_*.zip、php*.phar文件 - 尤其在频繁
composer create-project或 CI 构建中，临时文件可能残留数天不释放 - 手动进该目录，按修改时间排序，删掉所有
composer_*和过期的php*文件
真正占空间的大头是已安装包的源码，缓存通常只占几百 MB；但长期不用可能累积到 2–5 GB——而临时目录里的单个 composer_*.zip 就可能几百 MB，且没人管。
