Composer install 默认全量并发而非排队，因其解析依赖后并行处理下载解压以提升中小型项目速度；但200+大体积私有包在I/O或内存受限时易引发超时、OOM或进程被杀。
composer install 为什么不是“排队”，而是“全量并发”
Composer 默认不提供依赖安装的队列调度能力——它在解析完依赖树后，会把所有需要下载/解压/写入的包尽可能并行处理。这不是设计缺陷，而是为兼顾大多数中小型项目的安装速度。但当项目含 200+ 私有包、每个包 dist 包体积超 10MB、且部署机 I/O 或内存受限时，这种“全量并发”就会触发磁盘争抢、PHP 进程 OOM 或网络连接池耗尽，表现为 curl 超时、file_put_contents 失败或进程被系统 kill。
用 --no-plugins + 自定义脚本分批 install
Composer 原生不支持“按体积排序后分批 install”，但可通过绕过插件干扰 + 手动拆分依赖列表实现可控调度。关键点在于：禁用所有插件（尤其那些自动启用并发下载的旧版插件），再用脚本控制每次只 install 少量包。
-
composer install --no-plugins --no-dev --no-interaction --optimize-autoloader是安全基线，确保无插件副作用 - 从
composer.lock中提取包名与 dist size（可用jq '.packages[] | select(.dist.size) | "\(.name) \(.dist.size)"' composer.lock | sort -k2 -n） - 按 size 降序切分成每组 5–10 个包，生成临时
composer.json片段，仅保留该组 require 条目 - 对每组执行
composer install --no-update --no-scripts后再composer update vendor/package-a vendor/package-b ... --no-interaction
限制并发数和单包资源占用
Composer 2.2+ 支持 COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_MEMORY_LIMIT 环境变量，但真正影响瞬时负载的是网络与解压环节。以下参数组合可软性限流：
-
COMPOSER_NO_INTERACTION=1 COMPOSER_DISABLE_TTY=1：关闭所有交互与 TTY 检测，避免意外挂起 -
curl层面加限速（Linux/macOS）：alias curl="curl --limit-rate 2M"，防止单包下载吃光带宽 - 解压阶段无法直接限速，但可提前在私有包
composer.json中设"archive": {"exclude": ["/tests", "/docs", "/examples"]}，减小 dist 包体积 - 禁用
hirak/prestissimo类插件——它们已停止维护，且强制开启多线程反而加剧内存抖动
CI/CD 中更稳妥的替代路径
在 Jenkins/GitLab CI 等环境里，“让 Composer 排队”不如“让整个流程排队”。真实高负载场景下，推荐放弃在单次 composer install 内解决，改用构建缓存 + 分层还原：
- 基础镜像中预装常用公共包（
monolog,guzzlehttp/guzzle等），用composer install --no-dev --optimize-autoloader固化 - 私有包走单独构建流水线，产出压缩后的
vendor-private.tar.gz，通过tar -xf直接解压而非 Composer 安装 - 最终镜像构建阶段只运行
composer dump-autoload --classmap-authoritative，跳过所有下载与解压
真正难控的从来不是 Composer 的“调度逻辑”，而是 dist 包体积、私有源响应延迟、以及 PHP 进程在解压大 tar 时的内存分配行为——这些环节没有队列开关，只有提前裁剪和分层规避。
