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/*（仅限可信环境）
长期维护建议
这类问题反复出现，说明磁盘管理策略没跟上项目规模。真正容易被忽略的是：