composer不支持断点续传，所谓“续传”实为重试+缓存复用+vendor目录状态比对；中断后是否成功重试取决于失败阶段——下载中断会清临时zip重下，解压或写入中断则需手动清理vendor和缓存。
Composer 不做断点续传，所谓“续传”其实是重试 + 缓存复用 + 目录状态比对的结果。 它不会保存下载进度、不支持 HTTP Range 请求、也不保留半截 ZIP 文件。你看到的“接着下”，是它跳过了已解压成功的包，只重处理失败或未开始的部分——前提是 vendor/ 和缓存没被破坏。
为什么重试有时成功、有时直接报错
Composer 的 install/update 是分阶段执行的：先读 composer.lock，再逐个下载 dist ZIP，校验 SHA256，最后解压到 vendor/ 并写入 vendor/composer/installed.json。中断发生的位置决定后续行为：
- 若卡在下载阶段（如
cURL error 56或Content-Length mismatch），临时 ZIP 被自动删除，下次重试会重新下载该包 - 若卡在解压或写入阶段（如磁盘满、权限不足），
vendor/package-name目录可能残留不完整文件，installed.json可能被截断，导致后续运行报Invalid argument supplied for foreach() - 若
vendor/已存在且结构完整，Composer 会对比composer.lock和installed.json，跳过已安装包，只补漏
哪些错误必须手动清理 vendor 和缓存
遇到以下任一现象，别硬重试，直接清理：
Failed to extract vendor/package-name: unable to open archive-
The zip extension and unzip command are both missing（实际是 ZIP 损坏，不是缺扩展） -
Invalid argument supplied for foreach()（指向installed.json） - 反复卡在同一包、同一百分比，且
-vvv显示下载后立即校验失败
执行顺序不能错：
-
rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows） -
composer clear-cache（清掉损坏的 ZIP 缓存） - 再跑
composer install
如何让重试更稳、更快
不是靠“续传参数”，而是控制执行路径和依赖来源：
- 换国内镜像源是第一优先级：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 加
--no-plugins --no-scripts跳过非核心逻辑，降低失败面 - 显式声明
--prefer-dist，避免意外 fallback 到 git clone（尤其对大仓库） - 确认
php.ini中memory_limit≥ 1G、max_execution_time≥ 1800，否则解压大包时直接 OOM 或超时 - 检查
COMPOSER_CACHE_DIR是否可写、磁盘是否充足—— Composer 会在那里建临时 ZIP，写满就崩
真正麻烦的不是网络中断本身，而是中断后残留的半成品目录、损坏的缓存 ZIP、或被截断的 installed.json。这些状态 Composer 不会主动修复，也不会报明确错误，只会让下一次运行在奇怪的地方失败。动手前先看 -vvv 输出的最后一行，它往往暴露了真实断点位置。
