composer不支持多线程，仅通过异步i/o实现并发下载，默认并发数6；依赖解析完全单线程；优化应聚焦镜像源、--prefer-dist、http/2及io瓶颈。

Composer 本身不支持真正意义上的多线程并行拉取依赖——它用的是单进程、多协程（基于 curl_multi 或 ReactPHP 的异步 I/O），底层仍是 PHP 的同步运行时，没有 pthread 或 parallel 扩展参与。所谓“快感”，其实是并发 HTTP 请求带来的吞吐提升，不是 CPU 多核并行。

为什么 composer install 看起来很快？

Composer 默认启用并发下载（concurrent downloads），但具体行为取决于安装方式和配置：

• 使用 curl 作为下载器时，通过 curl_multi_exec 同时发起多个 HTTP 连接，复用连接池，减少 TCP 握手和 TLS 开销
• 使用 php-http/httplug + guzzlehttp/guzzle 时，若启用了 AsyncClient，也会走异步请求队列
• 并发数默认为 6（可通过 COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_CONCURRENCY 调整，但注意：该环境变量仅在 Composer 2.2+ 生效）
• 依赖解析（solve）阶段完全单线程，且无法跳过；只有下载和解压阶段能并发

如何确认当前是否启用了并发下载？

加 -v 或 --verbose 参数观察日志输出节奏：

composer install -v

如果看到类似以下交错出现的行（非严格顺序），说明并发生效：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

Downloading https://repo.packagist.org/p2/monolog/monolog.json
Downloading https://repo.packagist.org/p2/guzzlehttp/guzzle.json
Downloading https://repo.packagist.org/p2/symfony/polyfill-ctype.json

若全是逐个等待完成再开始下一个，则可能是：

• 你用了 --no-plugins 关掉了异步下载插件
• PHP 编译时没启用 cURL（导致回退到阻塞式 file_get_contents）
• 设置了 COMPOSER_CONCURRENCY=1
• 网络策略或代理拦截了多路复用（如某些企业 HTTPS 解密网关会破坏 HTTP/2 流）

想“更并行”？别碰多线程，试试这些真实有效的优化点

PHP 不适合 fork 多进程做下载（资源开销大、信号处理脆弱），也不推荐强行引入 parallel 扩展。更务实的做法是：

• 用 composer install --prefer-dist --no-suggest：跳过源码克隆和文档安装，.zip 包比 git clone 快得多
• 配置本地镜像源：composer config repo.packagist composer https://packagist.phpcomposer.com（国内用户）或自建 Satis / Toran Proxy，降低 RTT 和丢包率
• 开启 OPcache 并预热 Composer 自身（尤其在 CI 中）：php -d opcache.enable=1 /usr/bin/composer install
• 禁用防病毒实时扫描临时目录（vendor/ 解压常被卡住）
• 升级到 Composer 2.5+：HTTP/2 支持更稳，curl 下载器默认启用 HTTP/2，头部压缩 + 多路复用效果明显

真正的瓶颈往往不在“并发度”，而在 DNS 解析、TLS 握手、磁盘 I/O（尤其是解压时小文件写入）和源服务器响应延迟。调高 COMPOSER_CONCURRENCY 到 20 反而可能触发限流或 OOM —— 这点很容易被忽略。