根本原因是Composer默认cURL下载无断点续传且超时/内存限制过严；解决方案是预缓存解压包至COMPOSER_CACHE_DIR、调高PHP参数、换镜像源并降并发。

Composer下载大包时反复中断，根本原因是默认超时和内存限制太保守

Composer 默认用 curl 下载 ZIP 包，但对大体积包（如 Laravel 项目含 vendor 压缩包超 100MB）没做分块或断点续传支持。一旦网络抖动、服务器响应慢或 PHP 执行超时，composer install 就卡在 “Downloading …” 后报 cURL error 56: Failure when receiving data from the peer 或直接退出，重试又从头开始。

改用 zip 协议 + COMPOSER_CACHE_DIR 预缓存可绕过大文件直下

Composer 本身不支持 HTTP 分块下载，但能跳过 ZIP 下载阶段：把包提前解压到本地 cache，让 Composer 直接复制。关键不是“配置分块”，而是“避免下载大 ZIP”。

• 手动下载对应包的 ZIP（从 packagist.org 页面点开版本 → source 或 dist 链接）
• 解压后放入缓存目录对应路径：COMPOSER_CACHE_DIR/repo/packagist.org/provider-vendor-package.json 和 files/ 子目录
• 确保 composer.json 中该包版本锁定（如 "vendor/package": "1.2.3"），否则 Composer 可能忽略本地缓存
• 运行 composer install --no-interaction --prefer-dist，它会优先查 cache，跳过远程 ZIP 获取

php.ini 和 composer.json 的关键参数必须同步调高

即使走缓存，PHP 进程仍要解压、写入、校验大文件，低配值会导致 Allowed memory size exhausted 或 Maximum execution time exceeded。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 调整 php.ini：memory_limit = 2G（非 512M）、max_execution_time = 1800（30 分钟）、post_max_size = 512M、upload_max_filesize = 512M
• 在项目根目录加 composer.json 片段：

  "config": {
    "process-timeout": 3600,
    "fxp-asset": {"enabled": false},
    "github-oauth": {"github.com": "your_token"}
  }

• 禁用 fxp-asset（旧插件）可减少中间代理层失败概率；GitHub Token 能提升 API 限流阈值，间接加快元数据拉取速度

真要走网络下载，唯一可控的“分块”是换源 + 并发降级

没有真正的 HTTP Range 支持，但可通过镜像源 + 降低并发数，让单次请求更小、更稳。

• 国内推荐清华源：composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停）→ 改用 https://mirrors.tuna.tsinghua.edu.cn/composer/
• 强制降并发：composer install --no-interaction --prefer-dist --jobs=1（默认是 CPU 核数，高并发反而易触发服务器限流）
• 若用私有仓库，确认其 dist URL 返回的是真实 ZIP 地址（非 302 跳转链），跳转多层会放大超时风险

真正难处理的是 vendor 里某一个包的 dist ZIP 本身超过 500MB（比如含 docs/binaries），这种包本就不该进 Composer 流程——得推动作者拆分或改用 bin 独立分发。网络优化再强，也救不了设计上就反模式的大文件。