composer并发下载不依赖多线程或多进程，而是通过curldownloader的curl multi接口实现最多12个http请求的队列化调度与连接复用，失败请求自动重试且不阻塞其他任务。
Composer的并发下载不是靠“线程”或“进程”调度
Composer本身不启动多线程或多进程，它依赖底层 HTTP 客户端（主要是 CurlDownloader）的 cURL multi 接口实现并发请求。所谓“负载调度”，其实是 HTTP 请求队列 + 连接池 + 状态机协同的结果，不是传统意义上的 CPU 或 I/O 负载均衡。
关键点在于：HttpDownloader 维护一个最大并发数（$maxJobs，默认约 12），并按以下逻辑动态调度：
- 新任务进入
STATUS_QUEUED状态，等待空闲 slot - 有空闲 slot（
$runningJobs ）时，立即发起请求，状态切为 <code>STATUS_STARTED - 任一请求完成（无论成功/失败），释放 slot，从队列取下一个任务补上
- 失败请求会按策略重试（如
CURLE_OPERATION_TIMEDOUT最多重试 3 次），不阻塞其他任务
为什么不能简单调高 COMPOSER_MAX_PARALLEL_HTTP_REQUESTS
这个环境变量确实能覆盖默认并发上限，但盲目设高反而容易触发反效果：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 远程服务限流：Packagist 或镜像源（如阿里云、腾讯云）对单 IP 的并发连接数有限制，超限会返回
429 Too Many Requests或直接断连 - TCP 连接耗尽：PHP 的
cURL multi在高并发下会快速占满可用端口（尤其在 NAT 环境或容器中），表现为CURLE_COULDNT_CONNECT - 弱网下雪崩：丢包率高时，并发请求数越多，重试叠加越严重，整体耗时不降反升
- 本地资源争抢：PHP 进程本身是单线程的，过多并发请求会加剧内存分配与 GC 压力，尤其在低配 CI 机器上易 OOM
CurlDownloader 如何复用连接降低开销
连接复用（keep-alive）是 Composer 实现高效并发的关键一环，它不靠用户配置，而是由 CurlDownloader 自动管理：
- 对同一 host（如
mirrors.aliyun.com）的所有请求，复用同一个 cURL handle 和底层 TCP 连接 - 元数据请求（
packages.json）和 ZIP 下载请求被分到不同连接池，避免大文件传输阻塞小响应 - 若某连接异常关闭（如服务器主动断连），后续请求会自动新建连接，不影响队列中其他任务
- 不支持
Range头的镜像源（部分内网私有源）会导致并发下载失败并退回到串行模式，错误信息类似HTTP/1.1 416 Requested Range Not Satisfiable
真正影响调度效率的隐藏瓶颈
很多人盯着“并发数”，却忽略了更常卡住整个流程的非网络环节：
-
composer install后的dump-autoload是纯 CPU 单线程操作，无法并发，且 Laravel/Symfony 项目生成 classmap 时可能吃光内存 - 每个包解压后要执行
post-install-cmd脚本（如php artisan package:discover），这些脚本本身可能发起新的 HTTP 请求或数据库连接，形成隐式串行链 - 重复的
repositories配置（尤其是 type: "package" 或多个私有 Git 源）会让 Composer 对每个源都做一次元数据探测，哪怕最终没用到，也计入调度队列 - 未启用
--prefer-dist时，Composer 会为每个包先git clone，而 Git 协议本身不支持并发，且每次 clone 都要走完整 TLS 握手 + 对象传输，彻底绕过 HTTP 并发机制
调度逻辑再聪明，也救不了被 git clone 或 post-install-cmd 锁死的主线程——这才是生产环境最常被忽略的“伪慢”根源。
