Composer 2.1+ 默认启用并发下载，无需开启；若仍串行，主因是镜像响应慢、DNS卡顿或GitHub限流，应换国内镜像、清缓存、检查curl扩展并合理设parallel-downloads为6–8。
Composer 没有多线程模式，也不存在“开启”操作——所谓“并行下载”是并发 HTTP 请求，不是系统级多线程，强行找 --threads 或 -j 参数只会报 Unrecognized option 错误。
composer install 还在一行一行下载？先确认是否真卡在下载
很多用户以为“慢=没并行”，实际卡点常在别处：composer install -v 能暴露真实瓶颈。如果日志停在 Generating autoload files 或某个 post-install-cmd 上，调并发毫无意义；只有看到连续多行 Downloading https://... 且进度缓慢，才说明下载层是瓶颈。
- 串行下载是 Composer 默认行为，但 Composer 2.1+ 已默认启用并发请求（基于
curl_multi），无需额外开启 - 若仍表现为单行下载，大概率是镜像源响应慢、DNS 解析卡顿，或 GitHub API 被限流（未配 token 时每小时仅 60 次）
- 执行
composer config --global github-protocols https可避免 SSH 认证阻塞
parallel-downloads 配置只对 dist 包生效，且有实效上限
parallel-downloads 是 Composer 2.2+ 提供的实验性配置项，它控制的是最大并发请求数，不是线程数。设太高反而触发竞争或限流，设太低又浪费带宽。
- 推荐值为
6～8：全局执行composer config -g parallel-downloads 6 - 仅加速
--prefer-dist（默认）路径，对--prefer-source（git clone）完全无效 - 若报
file_put_contents(/tmp/): failed to open stream，说明临时文件冲突，立刻降到4 - CI 环境中建议固定该值，避免因机器差异导致构建时快时慢
hirak/prestissimo 插件只适用于 Composer 1.x，2.x 用户必须卸载
Composer 2.x 内置了更稳定的并发机制，hirak/prestissimo 不仅不兼容，还会导致依赖解析异常、composer.lock 结构错乱，甚至静默失效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Composer 2.5+ 用户运行
composer global remove hirak/prestissimo是必要清理动作 - 验证是否残留：执行
composer global show，列表里不应出现hirak/prestissimo - 若项目曾用 1.x + prestissimo 构建过，升级到 2.x 后建议删掉
vendor/和composer.lock重装 - 插件从未加速 autoloader 生成或脚本执行——那些环节始终单线程，别指望它解决全部问题
真正影响速度的，往往是镜像、缓存和 PHP 环境配置
比折腾并发数更关键的是让每次请求都更快、更稳、更少重试。国内用户不换镜像，开 20 个并发也白搭。
- 用阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清旧缓存：
composer clear-cache，否则可能读到过期元数据导致反复失败 - 确保
cURL扩展启用：php -m | grep curl，否则并发退化为串行 - CI 中加
--no-scripts --no-autoloader --no-dev --optimize-autoloader，跳过所有非必需环节
并发数、镜像、缓存、PHP 扩展状态——这四者缺一不可。漏掉任意一个，其他优化都会打折扣。
