proc_open(): fork failed 主因是内存或 swap 不足，而非进程数限制；应先检查 free -h 和 swapon --show，再考虑 ulimit -u 或 composer 并发参数优化。

proc_open(): fork failed 是内存不足，不是进程数限制

看到 proc_open(): fork failed，第一反应别急着调 ulimit -u。这个错误 90% 是物理内存或 swap 不足导致 fork() 失败，而不是系统对单用户进程数做了硬性限制。Linux 内核在内存紧张时会直接拒绝 fork 请求，报错却沿用旧名，容易误导。

验证方式很简单：free -h 看 available 是否长期低于 100MB；swapon --show 确认 swap 是否为 0。若两者都成立，加 swap 比改 ulimit 有效得多。

ulimit -u 真要调，得看实际值再动

运行 ulimit -u 查当前用户最大进程数。大多数 VPS 默认是 4096 或 8192，够 Composer 正常运行。只有当你确认日志里明确出现 Resource temporarily unavailable 且 free -h 显示内存充足时，才需怀疑是这个限制卡住。

• 临时提高（当前 shell 有效）：ulimit -u 8192
• 永久修改需编辑 /etc/security/limits.conf，加两行：
  youruser soft nproc 8192
youruser hard nproc 16384
• 注意：改完需重新登录终端，su - youruser 或新开 SSH 连接才生效

Composer 自身并发控制比系统级更直接

与其碰系统参数，不如先压 Composer 的资源胃口。它默认并行下载、解压、安装，每个环节都开子进程。用这几个参数组合，基本能绕过绝大多数 fork 失败：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• --max-jobs=1：强制串行，最有效
• --no-scripts：跳过 post-install-cmd 等脚本，省掉一堆 php 子进程
• --no-plugins：禁用所有插件，避免第三方扩展额外开进程
• --prefer-dist：优先下 zip 包而非 git clone，减少 exec 调用次数

完整命令示例：composer install --prefer-dist --no-plugins --no-scripts --optimize-autoloader --max-jobs=1

容器和 CI 环境里别硬扛，换策略

Docker 或 GitHub Actions 里遇到 fork failed，基本说明分配的内存太小（比如 GitHub Free tier 的 2GB）。这时候强行调 ulimit 或加 swap 都不现实。

更可行的做法：

• 本地或 CI 中高配节点跑 composer install，把 vendor/ 打包上传，部署时直接解压
• 用 composer install --dry-run 先验证依赖是否可解析，避免失败后浪费时间
• 拆分安装：composer install --no-dev 先装生产依赖，再单独处理 dev 包（如 phpunit）

真正容易被忽略的是：很多 CI 配置里写了 composer install 却没指定 --no-scripts，而某个开发依赖的 post-install-cmd 里又调了 node 或 python，瞬间把内存打爆——这类隐式依赖链，比 ulimit 更难排查。