Composer 2.1+ 默认启用并行下载，无需开启，但默认并发数仅3–6，需通过composer config -g http-max-concurrent-downloads 8调高，并配合国内镜像与清缓存才能真正提速。
Composer 2.1+ 默认已启用并行下载，不需要“开启”，但默认并发数太低（通常 3–6），且极易被网络、镜像、PHP 配置拖垮——调高 http-max-concurrent-downloads 并配国内镜像是唯一可靠提速路径。
composer install 还在一行一行下？先确认是否真不并发
不是没开，是并发被静默降级了。常见现象：Downloading https://... 日志严格顺序出现、CPU 占用低、网络连接数极少。这时要查三件事：
- 运行
composer --version，低于2.1必须升级：composer self-update - 执行
composer install -vvv，看日志里是否同时出现多个Downloading行；如果只有一条在动，说明并发被阻塞 - 检查 PHP 是否启用了
curl扩展：php -m | grep curl，没启用会退化为串行，且不报错
怎么调高并发数：只用一个 config 命令
http-max-concurrent-downloads 是 Composer 2.2+ 唯一有效的并发控制配置项，它直接限制 HTTP 请求池大小，影响所有下载命令（install、update、require）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局设为 8（多数机器的稳妥上限）：
composer config -g http-max-concurrent-downloads 8 - 临时覆盖（比如 CI 中）：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install - 别设超过 10：阿里云/腾讯云镜像在并发 >12 时容易返回
429 Too Many Requests；GitHub 源则可能触发403 rate limit exceeded
为什么调了并发还是慢？镜像和缓存才是瓶颈
并发再高，也救不了 DNS 解析慢、TLS 握手卡、源站响应差。国内用户 90% 的“慢”都源于此。
- 必须切国内镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（别用已停更的 phpcomposer.com） - 换镜像后立刻清缓存：
composer clear-cache，否则旧元数据仍走境外源 - 私有仓库若支持并发，需确保其响应头含
Accept: application/json，且不返回 302 跳转（否则 Composer 会 fallback 到串行流程）
哪些操作根本不受并发影响？别白费力气
并行下载只作用于「HTTP 包下载阶段」，其他环节全是单线程，强行加参数毫无意义。
-
composer dump-autoload、composer diagnose：不发网络请求，插件和并发配置完全不介入 -
composer install --no-plugins：显式禁用所有插件，prestissimo等第三方加速器失效 -
composer update的元数据拉取（即https://repo.packagist.org/packages.json）仍是串行，无法并行——这是设计限制，不是配置问题 - 解压 ZIP、写入
vendor/、生成 autoload classmap：磁盘 I/O 和 PHP 单进程瓶颈，和并发数无关；macOS APFS 或 Windows 启用实时杀毒时尤其明显
真正卡住的地方往往不是“下得慢”，而是某一个包的 post-install-cmd 挂起，或 opcache 缓存污染导致元数据解析卡死。开 -v 看停在哪一行，比盲目调并发有用得多。
