proc_open() fork failed 是系统资源限制所致，非 composer bug；因内核拒绝 fork 请求，常见于容器、低配vps或ulimit过严环境，本质是进程数超限（enomen/eagain）。
为什么 proc_open() fork failed 是资源问题，不是 Composer 本身 bug
这个错误根本不是 Composer 写错了，而是 PHP 在调用 proc_open() 时，系统无法再 fork 出新进程——内核拒绝了。常见于容器、低配 VPS 或 ulimit 设定过严的环境。PHP 进程本身没崩，是操作系统在底层拦下了 fork 请求。
- 典型触发场景：
composer install或composer update中下载包后执行脚本（如post-install-cmd），或并行安装多个包时瞬时进程数激增 - 不是所有 linux 都一样：centos 7 默认
/proc/sys/kernel/pid_max是 32768，但 docker 容器可能被 cgroup 限制到 1024 甚至更低 -
fork failed和Cannot allocate memory经常混发，但本质都是ENOMEM或EAGAIN系统错误，不是内存不足，是进程数/线程数超限
检查和临时绕过：快速确认是不是 ulimit 或 cgroup 限制
别急着改配置，先定位瓶颈在哪。Composer 启动子进程前会继承当前 shell 的限制，所以看它运行时的上下文更重要。
- 在执行
composer install前，运行ulimit -u查用户级最大进程数（注意：Docker 中该值常为 1024，且不可靠） - 进容器后查 cgroup 限制：
cat /sys/fs/cgroup/pids.max 2>/dev/NULL || echo "not using pids cgroup" - 临时放宽（仅测试用）：
ulimit -u 8192 && composer install，如果成功，基本锁定是ulimit -u问题 - Docker 用户重点看启动参数：
--pids-limit=8192比--ulimit nproc=8192:8192更准，后者在较新内核中可能被 cgroup v2 忽略
永久修复：宿主机、容器、PHP 层三处必须协同调整
单改一处大概率白忙。宿主机设了上限，容器不透传；容器开了，PHP 进程没继承；PHP 继承了，Composer 又用 proc_open() 走了另一条路——全得对上。
- 宿主机（systemd 环境）：
sudo systemctl edit docker→ 加[Service]nTasksMax=infinity，然后sudo systemctl restart docker - Docker run 时显式传参：
docker run --pids-limit=8192 --ulimit nproc=8192:8192 ...（nproc对非 root 容器才生效） - PHP-FPM 或 CLI 环境中，确保没在
php.ini或 pool 配置里写死rlimit_nproc；CLI 下可加php -d "rlimit_nproc=-1" $(which composer) install强制解除 - Composer 自身无进程数配置项，不要试图改
config.json里的process-timeout或fxp-asset——它们完全不解决 fork 失败
替代方案：当改不了系统限制时，怎么让 Composer 少 fork
有些环境你就是没法调高限制（比如共享主机、CI 平台的默认 runner）。这时候只能压低 Composer 的并发行为，减少 fork 频次。
- 禁用并行安装：
composer install --no-plugins --no-scripts --no-autoloader，之后分步执行脚本，避免一次性拉起大量子进程 - 关掉所有插件：
COMPOSER_DISABLE_XDEBUG_WARN=1 composer install --no-plugins，某些插件（如hirak/prestissimo）自己也会 fork - 换源 + 离线模式：用
composer config repo.packagist composer https://packagist.phpcomposer.com（国内镜像），减少网络超时引发的重试 fork；更彻底的是composer install --prefer-dist --no-interaction，跳过 git clone 步骤（git 最爱 fork） - 注意：
--no-dev不减少 fork 数量，只是跳过 dev 依赖的脚本执行，但核心安装流程 fork 量不变
真正卡住的地方往往不是“该不该调大”，而是改了宿主机却忘了容器参数，或者容器设了 --pids-limit 却没配 --ulimit 导致 PHP 进程自己先被限死了。两个限制必须同时满足，缺一不可。