该错误源于PHP调用proc_open()时系统fork失败，主因是内存不足、进程数超限（RLIMIT_NPROC）或容器资源配额过严；需调整ulimit -u限制、降低Composer并发度（如--concurrency=1）、避免Git操作，并在Docker/CI中显式配置ulimit。
为什么 Composer 会报 proc_open(): fork failed
这个错误不是 Composer 本身的问题，而是 PHP 在调用系统 proc_open() 创建子进程时失败了。根本原因是操作系统级资源耗尽：通常是 fork() 系统调用被内核拒绝，常见于内存不足、进程数超限（RLIMIT_NPROC）、或容器环境资源配额过严。尤其在 CI/CD 环境（如 GitHub Actions、GitLab Runner）或低配 VPS 上高频出现。
检查并调整系统进程数限制（RLIMIT_NPROC）
PHP 子进程（如 Git、unzip、php-cs-fixer）都算作用户进程。默认限制可能只有 300–1024，而 Composer install 可能瞬间启动数十个并发进程。
- 查看当前限制：
ulimit -u
- 临时提高（当前 shell 有效）：
ulimit -u 4096
- 永久生效需修改
/etc/security/limits.conf，添加：* soft nproc 4096
（注意：需重启登录或重载 PAM）
* hard nproc 4096 - 在 systemd 服务中（如 PHP-FPM 或 CI runner），需显式设置：
LimitNPROC=4096
降低 Composer 并发度和禁用不必要的功能
减少子进程峰值数量是最直接的缓解方式。Composer v2 默认启用并行安装，但某些环境无法承受。
- 禁用并行安装：
composer install --no-plugins --no-scripts --no-interaction -n --no-progress
（去掉--no-progress反而可能增加终端控制进程开销） - 强制串行执行：
COMPOSER_PROCESS_TIMEOUT=600 COMPOSER_MEMORY_LIMIT=-1 composer install --concurrency=1
- 跳过 Git 操作（避免 spawn git 进程）：
composer config -g github-oauth.github.com "your-token"
并设composer config -g secure-http false（仅限可信内网） - 用
--prefer-dist而非--prefer-source，避免触发git clone
Docker 容器中特别要注意的点
很多 CI 使用 Docker 运行 Composer，但默认容器未继承宿主机的 nproc 限制，且 cgroup v2 下行为更严格。
- 启动容器时显式传入：
docker run --ulimit nproc=4096:4096 ...
- GitHub Actions 中，在
container配置下加options: --ulimit nproc=4096:4096 - 若用
alpine镜像，确认 glibc 兼容性（musl 不完全等价），建议优先用debian:slim或官方php:8.2-cli - 避免在
ENTRYPOINT中直接调用composer install—— 改为 shell 脚本并提前ulimit -u 4096
真正卡住的地方往往不是 Composer 参数，而是容器或 CI runner 的 ulimit 配置没生效，或者 --concurrency=1 没覆盖到所有子命令（比如插件仍会自行 fork）。先查 ulimit -u 输出，再看是否真进了容器内部执行，这两步漏掉一个就白调参数。
