composer不支持断点续传，所谓“续传”实为重试+缓存复用+vendor目录状态比对；中断后能否成功重试取决于失败阶段——下载中断会清临时zip重下，解压或写入中断则需手动清理vendor和缓存。
Composer 不支持断点续传——这句话不是提醒，是事实。所谓“支持断点续传的镜像”，根本不存在。所有公开镜像（阿里云、腾讯云、华为云等）都不提供 HTTP Range 请求支持，Composer 本身也不发 Range 请求，更不会保存下载进度或复用半截 ZIP 文件。
那为什么有人重试几次就成功了？只是因为运气好，或者中断发生在可跳过的阶段，不是镜像“支持续传”。
为什么你看到的“重试成功”不是断点续传
Composer 的“恢复”靠三件事：composer.lock 校验、vendor/ 目录比对、缓存 ZIP 复用。它不记录“第 123MB 下到哪了”，只记住“monolog/monolog 已解压完成”。所以：
- 中断发生在元数据拉取阶段（如
packages.json下载失败）：重试几乎总能过，没写任何临时文件 - 中断发生在 ZIP 下载中：临时 ZIP 被自动删除，重试就是重新下载整个包
- 中断发生在解压或写
installed.json时：文件可能损坏或截断，composer install会直接报错，比如Invalid argument supplied for foreach()或Failed to extract
composer install 卡在 downloading 就一定是网络问题？
不一定。常见真实原因包括：
- 镜像节点返回
502 Bad Gateway（比如阿里云华东节点 CDN 异常），但你本地查不到——curl -I https://mirrors.aliyun.com/composer/返回超时或 502 就是证据 - 包类型是
"type": "vcs"或指定了"source"，Composer会绕过镜像直连 GitHub，走git clone，此时换镜像完全无效 - 镜像同步延迟：某包刚发布，镜像还没同步，
Composer查不到 dist URL，退而求其次走 source，触发 git 克隆，慢且易中断
验证是否真走镜像：运行 composer config -g repo.packagist，确认输出的 url 字段是你配的完整地址（注意末尾必须有 /），且 curl -I 能拿到 200。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
真正有效的“续传替代方案”
既然没有断点续传，就得用确定性更强的操作代替盲目重试：
- 强制走 dist 包：
composer install --prefer-dist --no-plugins --no-scripts，避免意外 fallback 到 git clone - 加重试次数：
composer install --retries=8（默认仅 3 次），对5xx错误有效，对认证类错误无效 - 手动清理再重来（别跳步）：
rm -rf vendor && composer clear-cache && composer install，尤其当报Corrupted zip file或installed.json截断时 - 换具体地域节点 URL，而非泛域名：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer-cn-beijing/，华北节点比默认华东更稳
别碰这些“看起来有用”的操作
以下动作不仅无效，还容易让问题更糟：
- 手动编辑
vendor/composer/installed.json补内容——校验失败后Composer直接拒绝加载 - 只删
vendor/却不清缓存——损坏 ZIP 还在~/.composer/cache/files/里，重装立刻复用并报错 - 在
composer.json里加"timeout": 600——这个字段根本不控制下载超时，真正起作用的是全局process-timeout - 反复
composer update十几次——缓存越积越多，磁盘占满后反而触发新错误
最常被忽略的一点：低带宽下，“暂停安装”唯一靠谱的方式，是主动保存 vendor/ 状态（比如压缩打包或 git stash --include-untracked），而不是指望 Composer 自己恢复。它从不把 vendor/ 当中间产物，只当最终结果。
