Composer 下载中断后卡在 Downloading... 是因磁盘写入失败未清理损坏缓存，导致反复尝试写入；应先停进程、查 cache-dir、用 du 找大目录，再安全清缓存并配置禁用 ZIP 和源码缓存。
Composer 下载中断后 composer install 一直卡在 Downloading...
这不是网络问题，是 Composer 在磁盘写入失败后没清理临时文件，导致下次运行时反复尝试写入同一损坏的缓存包。它不会自动跳过或重试，而是死等磁盘空间释放——但你可能根本没意识到缓存目录也在吃空间。
- 先查
composer config cache-dir确认缓存路径，默认通常是~/.composer/cache - 用
du -sh ~/.composer/cache/* | sort -hr | head -5找出最大的几个子目录，常见是files/和repo/占大头 - 别直接
rm -rf ~/.composer/cache：Composer 正在运行时删缓存可能引发file_put_contents(): No space left on device错误，得先停掉所有composer进程（包括 IDE 内嵌的） - 删完执行
composer clear-cache，它会重新校验并重建索引，比手动删更安全
如何让 Composer 少占磁盘空间？
默认行为是缓存所有下载的 ZIP 包 + 解压后的源码 + repo 元数据，对 CI 或低配服务器很不友好。关键是关掉非必要缓存项，而不是只清一次。
- 禁用 ZIP 缓存：
composer config --global cache-files-ttl 0（设为 0 表示不缓存 ZIP） - 禁用解压后源码缓存：
composer config --global cache-files-maxsize 0（单位 MB，0 = 不缓存） - 保留 repo 缓存（
cache-repo）即可，它只存 JSON 元数据，体积小且加速依赖解析 - CI 场景下建议加
--no-cache参数运行，比如composer install --no-cache --no-interaction
Could not write to /path/to/vendor 但磁盘明明还有空间？
常见于容器或挂载卷场景：宿主机磁盘够，但容器内 /tmp 或 /root/.composer/cache 所在分区满了，或者 inode 耗尽。Composer 写缓存和解压时大量创建小文件，容易触发 inode 限制。
- 检查 inode 使用率：
df -i，尤其关注/tmp和缓存目录所在挂载点 - 临时解决：用
composer config --global cache-dir /mnt/big-disk/composer-cache指向空间充足的路径 - 避免解压到
/tmp：Composer 本身不提供参数改解压中转目录，但可通过环境变量COMPOSER_CACHE_DIR统一控制（优先级高于 config） - 如果用 Docker，记得在
docker run里加-v /host/cache:/root/.composer/cache，别依赖默认绑定
下载中断后强行继续的危险操作
有人会去 vendor/ 里手动补文件、改 composer.lock 时间戳，或者删一半再重跑——这大概率导致依赖版本错乱或 autoloader 失效，因为 Composer 的原子性保障全在 install 流程里，中途打断就等于状态残缺。
- 正确做法只有两个：
rm -rf vendor composer.lock && composer install（干净重来），或composer update --lock（仅更新 lock 文件，不重装） - 别信
composer install --ignore-platform-reqs能绕过空间问题——它只跳过 PHP 扩展检查，不减少磁盘写入 - 如果项目有大量私有包，提前在空间充足机器上跑
composer install --no-dev打个完整vendor.tar.gz，部署时直接解压，彻底避开下载环节
最麻烦的不是空间不够，是 Composer 报错信息从不提「磁盘」二字，只说「failed to write」「cannot download」，你得自己顺着日志里的路径一层层 df 过去。缓存目录、临时目录、vendor 目录，三个地方都得盯住。
