该错误源于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
  * hard nproc 4096

  （注意：需重启登录或重载 PAM）
• 在 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 输出，再看是否真进了容器内部执行，这两步漏掉一个就白调参数。

# php  # git  # docker  # composer  # github  # 操作系统  # ai  # gitlab  # 为什么  # 继承  # 并发  # http  # debian  # 会报  # 内存不足  # 并在  # 进了  # 要注意  # 镜像  # 再看  # 不完全  # 而非  # 仅限