Composer并发下载数可通过COMPOSER_MAX_JOBS环境变量（如COMPOSER_MAX_JOBS=4）或composer config -g max-jobs 2命令调整，默认12；不支持--max-jobs参数，降并发优先于调timeout，配合国内镜像源效果最佳。
composer install/update 的并发下载数怎么调
Composer 默认最多并发 12 个 HTTP 请求（$maxJobs=12），这在带宽充足、镜像响应快时是优势，但在弱网、低配 CI 环境或共享出口 IP 场景下，容易触发限流或连接拒绝。它不是“调度频率”概念，但直接决定单位时间内的网络请求数量。
调整方式只有两个有效入口：
-
COMPOSER_MAX_JOBS=4环境变量 —— 推荐，全局生效且优先级高，Docker 或 GitHub Actions 中可直接设为COMPOSER_MAX_JOBS: 2 -
composer config -g max-jobs 2—— 写入全局配置，适合开发者本地统一约束
注意：--max-jobs=2 命令行参数不存在；改 process-timeout 对并发无影响；某些旧插件（如 hirak/prestissimo）已废弃，强行启用反而破坏原生并发控制逻辑。
为什么 --timeout 不等于“限频”，还可能让网络更糟
--timeout=600 只延长单次命令总生命周期，不降低请求密度。反而可能掩盖真实瓶颈：比如网络卡顿导致某个包反复重试（Composer 默认重试 3 次），每次重试都占满一个并发 slot，实际请求数翻倍，加重出口压力。
真正该盯的是错误类型：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 出现
CURLE_COULDNT_RESOLVE_HOST或503 Service Unavailable→ 优先切镜像源，不是加 timeout - 大量
Connection refused或Too many requests→ 说明服务端已限流，必须降max-jobs或加代理层排队 - 下载中途卡在某个 zip 包 → 检查
--http-basic-timeout（Composer 2.2+ 才支持），它单独控制单个 HTTP 连接超时，避免一个慢请求拖垮全部并发
用自定义 downloader 实现请求节流是否可行
技术上可以，但不推荐。Composer 的 CurlDownloader 是封闭实现，替换需继承并重写 download() 和任务调度逻辑，还要绕过 HttpDownloader 的 job 队列管理。实操中几乎没人这么做，因为：
- Composer 本身不暴露 downloader 注册接口，必须 patch vendor 或用插件 hook，升级即失效
- 节流逻辑（如令牌桶）需依赖外部存储（Redis/APCu）才能跨进程一致，而 Composer 主进程不维护长连接或状态上下文
- 80% 的“网络负载高”问题，根源是没切国内镜像源或
max-jobs设得过高，而非缺少节流器
真有强节流需求（如企业内网灰度发布），应在网络层做：用 nginx 代理 Composer 流量，用 limit_req 控制每 IP 每秒请求数。
CI/CD 中最稳妥的网络负载控制组合
GitHub Actions、GitLab CI 等环境资源受限，盲目信任默认值最容易失败。以下三者必须同时配：
-
COMPOSER_MAX_JOBS: 2—— 把并发压到最低安全水位 -
COMPOSER_PROCESS_TIMEOUT: 900—— 防止单次重试耗尽 timeout，给重试留空间 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 国内必做，比任何参数调优都管用
漏掉任意一项，都可能在某次 update 中突然因 DNS 波动、镜像瞬断或临时限流而失败——这些不是 Composer 的 bug，而是它把底层网络不确定性如实暴露了出来。
