Composer安装失败提示“Disk limit reached”本质是系统临时目录或用户主目录磁盘空间耗尽或受配额限制，因解压包、生成autoloader和写缓存会大量占用/tmp或~/.composer/cache空间，尤其大包解压峰值达2–3倍体积。
Composer 安装失败提示 Disk limit reached，本质不是 Composer 本身的问题，而是系统临时目录（/tmp）或当前用户主目录磁盘空间耗尽，或被配额限制。
为什么 composer install 会触发磁盘空间不足？
Composer 在解压包、生成 autoloader、写缓存时，会大量使用临时文件。默认行为是：
- 把 zip 包下载到
~/.composer/cache/files/ - 解压过程依赖系统
/tmp（Linux/macOS）或%TEMP%（Windows），尤其大包（如 Laravel、Symfony 全栈）解压时峰值占用可达 2–3 倍包体积 - 如果用的是共享主机或 CI 环境（如 GitHub Actions 默认 14GB SSD），
/tmp可能和根分区共用，且无显式告警
快速定位真实瓶颈位置
别急着删缓存——先确认到底哪块满了：
- 运行
df -h /tmp（Linux/macOS）或df -h /查看根分区使用率 - 检查 Composer 缓存大小：
du -sh ~/.composer/cache/ - CI 环境中注意：GitHub Actions 的
/tmp是内存盘（tmpfs），默认上限 1GB；GitLab Runner 若配置了docker tmpfs也会受限 - 某些托管平台（如 cPanel、Plesk）对单用户配额做了限制，
quota -u $USER可查看（需权限）
绕过磁盘限制的实操方案
不依赖扩容，优先改路径或跳过非必要写入：
- 强制 Composer 使用更大空间的临时目录：
COMPOSER_CACHE_DIR=/path/to/larger/disk/composer-cache composer install - 禁用 zip 解压缓存（省空间但略慢）：
composer install --no-cache - 跳过 autoload 生成（开发环境可接受）：
composer install --no-autoloader，之后手动跑composer dump-autoload - 清理旧缓存（安全）：
composer clear-cache—— 注意它只清~/.composer/cache/，不影响/tmp - CI 场景下，在
composer install前加一步：sudo rm -rf /tmp/*（仅限可信环境）
长期维护建议
这类问题反复出现，说明磁盘管理策略没跟上项目规模。真正容易被忽略的是：
- Composer 缓存默认永不过期，
~/.composer/cache/一年可能涨到 10GB+，建议每月 cron 清理：find ~/.composer/cache -type f -mtime +30 -delete - 某些私有 Packagist 镜像未开启压缩传输，导致下载体积翻倍，检查
composer config repo.packagist.org.url是否指向带https://packagist.org的原始源 -
/tmp被 mount 为 tmpfs 时，大小由内核参数控制（tmpfs size=2G），重启后重置——这种限制在容器或 CI 中极难察觉
