Composer install 不会自动续传是因为其不支持 HTTP 断点续传、不校验下载进度，仅在解压前比对 Content-Length，缓存中损坏 ZIP 会导致重试失败；有效恢复需清缓存、删 vendor、换镜像、调超时参数。
直接运行 composer install --retry=3 通常无效——中断后缓存里可能已存半截损坏的 ZIP，重试只会反复校验失败。
为什么 composer install 不会自动续传
Composer 本身不支持 HTTP 断点续传（Range 请求），也不校验下载进度，只在最后一步解压前比对 Content-Length 和实际字节数。一旦网络中断、代理截断或 CDN 返回异常头，就会卡死或报 Content-Length mismatch。
- 它不会记录“已下 65%”，也不会跳过已写入磁盘的部分
- 所有下载都走
cURL，失败后默认不重试；--retry只对全新请求生效，对损坏缓存无效 - 缓存路径
~/.composer/cache/files/下的 ZIP 文件若不完整，下次安装仍会复用并立刻失败
真正有效的恢复步骤
别重试，先清掉污染源，再触发全新拉取：
- 运行
composer clear-cache—— 清空~/.composer/cache/files/下所有 ZIP 和元数据 - 删掉
vendor/目录（rm -rf vendor或rd /s /q vendor） - 确认
composer.lock未被手动修改；如有疑虑，可先备份再删 - 执行
composer install --no-cache—— 强制跳过本地缓存，直连镜像源重新下载
换源 + 超时参数必须同步配
国内用户中断高频，往往不是网络真断了，而是默认超时太短或镜像不可用：
- 换当前可用镜像：用
composer config -g repos.packagist composer https://packagist.mirrors.ustc.edu.cn/（中科大）或https://mirrors.cloud.tencent.com/composer/（腾讯） - 调高 HTTP 超时：
composer config -g http.timeout 1200（单位秒，避免弱网下cURL error 28） - 调高进程超时：
composer config -g process-timeout 1800（防git clone卡住） - 验证是否生效：
composer diagnose看 “Repo packagist.org” 行是否显示你配的镜像域名
手动补一个总卡住的大包（如 laravel/framework）
如果反复中断在同一个包，说明它体积大、镜像同步慢或 GitHub 直链被干扰：
- 从
composer.lock找该包的dist.url字段（例如"https://api.github.com/repos/laravel/framework/zipball/..."） - 用
wget -c <url>或curl -C - -L <url> -o /tmp/pkg.zip手动下载（支持断点续传） - 算出该包的 SHA256（
shasum -a 256 /tmp/pkg.zip），对应到composer.lock的dist.shasum - 把 ZIP 放进缓存目录：
~/.composer/cache/files/<vendor>/<name>/<shasum>.zip - 再跑
composer install --no-plugins --no-scripts跳过其他动作，只解压这个包
这步容易错在路径命名和哈希值不匹配，建议只在 CI 或反复失败时用，日常优先走清缓存 + 换源 + 加超时三件套。
