Composer 不支持断点续传，因其下载的 ZIP 包需完整 SHA256 校验，且 GitHub 等源不支持 Accept-Ranges、URL 内容不固定；中断后会清空临时文件重试，但可通过镜像源、缓存目录或手动预置 ZIP 加速。
Composer 安装包下载中断后默认不支持断点续传，composer install 或 composer update 会直接清空已下载的临时文件并重试，这不是 bug，而是设计如此——因为 Composer 的下载逻辑基于完整 ZIP 包校验（SHA256），中间文件不可复用。
为什么 Composer 不做断点续传
Composer 下载的是由 Packagist 签名分发的 ZIP 归档（如 https://api.github.com/repos/monolog/monolog/zipball/...），其响应头不含 Accept-Ranges，且服务端不保证同一 URL 多次请求返回相同内容（例如 GitHub 的 zipball URL 带临时 token）。更关键的是，Composer 在下载完成后必须校验整个 ZIP 的 sha256 值，任何局部文件都无法跳过校验流程。
临时目录被清空导致重下全部
当下载中断时，Composer 会在 vendor/composer/tmp-xxxxx.zip 写入不完整 ZIP，但下次运行时会检测到该文件校验失败，自动删除它并新建临时文件。你看到“又从 0% 开始”，其实是这个清理行为造成的假象。
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- 可通过设置
COMPOSER_CACHE_DIR指向一个可读写的稳定路径，避免因权限或磁盘满导致意外中断 - 检查
~/.composer/cache/files/（或COMPOSER_CACHE_DIR/files/）是否有已缓存的完整 ZIP：如果某个包此前成功安装过，Composer 会直接解压缓存，不重新下载 - 不要手动修改
vendor/composer/下的 tmp 文件——它会被立即覆盖
真正可行的加速方案
绕过网络下载瓶颈，改用本地缓存或镜像源：
- 国内用户优先配置阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 启用
composer install --prefer-dist（默认行为），确保走 ZIP 分发而非 Git 克隆 - 若已有完整 ZIP 包（比如从同事处拷贝），可放入缓存目录：
~/.composer/cache/files/vender/package-name/xxx-sha256.zip，Composer 会自动识别并跳过下载 - 极端慢速网络下，可先用
wget -c或curl -C -手动下载 ZIP 到缓存目录，再运行composer install
最常被忽略的一点：Composer 的“下载失败”提示往往不是网络问题，而是 DNS 解析超时或 TLS 握手失败（尤其在企业代理后），此时换镜像源比调什么断点参数有用得多。
