确认并行下载是否真在运行，需观察composer install -vvv实时日志：若同一秒内多行“downloading”或进度条跳跃式推进（如5/42→14/42→22/42），说明并发已激活；否则可能镜像未生效或dns未绕过。唯一有效配置是http-max-concurrent-downloads（默认6），全局设为8～10最稳妥，设过高易触发临时文件竞争或镜像限流416错误；parallel-downloads已弃用。必须配合阿里云或清华源（https://mirrors.tuna.tsinghua.edu.cn/composer/）并执行composer clear-cache，且确保无项目级repositories覆盖全局配置。
怎么确认并行下载真在跑，而不是假提速
别只看命令加了参数，重点盯 composer install -vvv 的实时日志：如果同一秒内出现多行 Downloading https://mirrors.aliyun.com/...，或进度条从 (5/42) 跳到 (14/42) 再跳到 (22/42)，说明并发已激活；如果始终单行输出、卡在某个包不动，大概率是镜像没生效，或者本地 DNS 缓存没绕过。
该设 http-max-concurrent-downloads 还是 parallel-downloads
parallel-downloads 是 Composer 2.2 初期短暂用过的配置名，已在 2.2+ 正式弃用——设了也不生效，还容易让你误以为自己调高了并发。唯一有效的配置项是 http-max-concurrent-downloads，默认值通常是 6。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局设为 8～10（稳妥上限）：
composer config -g http-max-concurrent-downloads 8 - 设成 20 或更高，容易触发
file_put_contents(/tmp/): failed to open stream（临时文件竞争）或镜像站限流返回416 - 这个配置只对
composer install生效；composer update因依赖图需实时解析，底层仍有强串行逻辑
镜像源配错，并发再高也白搭
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析或 TLS 握手，开 10 个线程等于 10 个排队窗口。必须确保：
- 全局换阿里云源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清华源新地址是：
https://mirrors.tuna.tsinghua.edu.cn/composer/（旧的packagist.phpcomposer.com已停用） - 换源后必须清缓存：
composer clear-cache，否则旧元数据仍尝试回源 - 验证是否生效：
composer config -g repo.packagist输出应为完整 HTTPS URL，不能是null或空值
CI/CD 中最容易被忽略的并发陷阱
项目级 composer.json 中存在 "repositories" 字段，会完全覆盖全局镜像配置——你设了 http-max-concurrent-downloads 10，但实际请求全走境外源，根本没进镜像。
- 要么删掉项目级
repositories，要么显式把镜像 URL 写进去，并加{"packagist.org": false} - 某些私有镜像不支持
Range请求头，强行高并发会返回416 Requested Range Not Satisfiable - Docker 环境中若禁用了
opcache.enable_cli，会导致依赖解析变慢，间接拖垮并发吞吐
