composer install 中断后无法自动续传，因其底层 curl 或 php stream 不支持 http range 请求，下载失败即丢弃整个 zip 包，缓存中仅留空文件夹或损坏文件，且无断点记录；手动恢复需依赖 vendor/composer/installed.json 和全局缓存中的完整 zip 文件，配合 --no-scripts --no-plugins 选项跳过已安装包；国内用户应优先换阿里云镜像源、限制并发数、预拉取大包，并排查 cache-dir 权限问题。
Composer install 中断后为什么不能自动续传
因为 Composer 默认用的 curl 或 php stream 下载，底层不支持 HTTP Range 请求，zip 包下载失败就整个丢弃，缓存目录里只留了个空文件夹或损坏的 .zip，下次运行 composer install 会直接删掉重下——不是它不想续，是根本没记“下到哪了”。
手动恢复下载的关键：定位并复用 vendor/composer/installed.json + cache 目录
Composer 的缓存实际分两层：全局 ~/.composer/cache（含 dist zip 和 archive）和项目级 vendor/composer/installed.json（记录已成功解包的包名与版本）。中断后只要 installed.json 里已有部分条目，就能跳过那些包的下载与安装。
- 先确认缓存是否有效：
composer config --global cache-dir查路径，进该目录看files/下有没有对应包的完整.zip（大小接近官网 size） - 如果 zip 存在但没解包，删掉项目
vendor/，保留vendor/composer/installed.json，再跑composer install --no-scripts --no-plugins，它会跳过已记录的包，只处理缺失部分 - 若
installed.json是空的或不存在，别硬试续传——直接清缓存composer clear-cache，改用--prefer-dist --no-progress减少干扰重来
国内用户绕过中断的实用组合技
网络不稳定是主因，单纯依赖缓存恢复效率低。更可靠的是从源头降低失败概率：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 换镜像源：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该源已停，推荐https://mirrors.aliyun.com/composer/） - 限制并发数防超时：
composer install --prefer-dist -v --max-workers=2（默认是 CPU 核数，高并发易触发 DNS 或连接池耗尽） - 对大包（如
laravel/framework）单独预拉取：composer require laravel/framework:10.42.0 --no-update→composer update laravel/framework --prefer-dist，拆解压力
cache-dir 权限错误导致“看似恢复实则重下”的坑
常见现象：明明缓存目录有 zip，composer install 却仍显示 “Downloading … 0%”，日志里出现 Failed to create cache directory 或 file_put_contents(/xxx/cache/files/…): failed to open stream。
根本原因不是网络，是当前用户对 cache-dir 没有写权限（尤其 Docker 容器或 sudo 后切换用户）。检查方法：ls -ld $(composer config --global cache-dir)，确保属主匹配当前执行用户。临时修复：sudo chown -R $USER:$(id -gn) $(composer config --global cache-dir)。
这个权限问题一旦存在，所有缓存都失效，所谓“恢复下载”只是幻觉。
