答案是缓存目录或临时解压路径占满用户磁盘配额；需先用composer clear-cache清理缓存，检查~/.composer/cache或%APPDATA%\Composer\Cache大小，超500MB则手动删残留ZIP/临时文件，或改用--no-cache、换大分区缓存路径，并排查vendor/临时目录及quota限制。
Composer install 报 Disk quota exceeded 怎么办
这不是磁盘真满了，而是 Composer 的缓存目录或临时解压路径占用了配额（quota），尤其在云服务器、容器、学校机房账号等有用户级磁盘限额的环境里，df -h 显示还有几十 GB 空间，照样会崩。
先确认是不是缓存目录撑爆了
Composer 默认把下载的包缓存在 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows），多次失败安装后残留大量未清理的 .zip、.tar 和 extracted/ 文件夹，它们不随 composer install 成功与否自动删除。
- 运行
composer clear-cache—— 这是最安全的第一步，能清掉所有已下载但未安装的包和提取物 - 手动检查缓存大小：
du -sh ~/.composer/cache（Linux/macOS）或Get-ChildItem %APPDATA%\Composer\Cache -Recurse | Measure-Object -Property Length -Sum（PowerShell） - 如果缓存 >500MB，大概率就是它在作祟；某些项目反复
update后缓存可达 2GB+
临时禁用缓存或换地方存放
缓存不是必须的，尤其在 CI/CD 或一次性的部署场景里，禁用反而更快、更省空间。
- 加
--no-cache参数：composer install --no-cache，跳过读写缓存，直接下载安装 - 换缓存目录到大分区：
composer config --global cache-dir /path/to/larger/disk/composer-cache，比如指向/tmp或挂载的 SSD 分区 - 注意 Windows 用户：避免把缓存设在 OneDrive 或 Dropbox 同步目录下，文件锁和同步延迟会引发
rename(): Permission denied类错误
别漏掉 vendor 目录本身的临时文件
composer install 在解压包时，会在 vendor/ 下建临时目录（如 vendor/composer/xxxxx-temp），若中途失败，这些残留可能卡住后续执行，且不计入 composer clear-cache 范围。
- 删干净再试：
rm -rf vendor/ composer.lock（确保composer.json正确），然后重跑composer install - 如果用的是 Docker，检查容器是否挂载了
vendor到宿主机小容量卷，或者/tmp被限制为内存盘（tmpfs）且 size 不足 - 某些共享主机对单个用户
vendor/目录 inode 数量也有限制，ls -la vendor/ | wc -l超过 10 万就要警惕
真正容易被忽略的是：配额（quota）和磁盘空间（disk space）是两回事。系统管理员设的 per-user block limit 或 inode limit，df 看不出来，得用 quota -u $USER（Linux）或联系运维查。这时候清缓存、换路径、禁用缓存，比盲目删项目文件管用得多。
