“proc_open(): fork failed - Cannot allocate memory”是系统内存不足所致，需添加1GB Swap并执行dd、mkswap、swapon三步解决，而非修改PHP配置或Composer参数。

“proc_open(): fork failed - Cannot allocate memory” 不是函数被禁，而是系统真没内存了。加 swap 是最快见效的解法，别先去改 PHP 配置或 composer 参数。

确认是不是内存耗尽，而不是函数被禁

看到 proc_open(): fork failed 就去删 disable_functions 或加 --no-scripts，大概率白忙——这两类操作对 fork 失败完全无效。真正要查的是系统资源：

• 运行 free -m，看 Swap 行是否为 0；若 Mem 剩余不足 100MB，基本可锁定内存问题
• 运行 ulimit -v 和 ulimit -n，检查虚拟内存和文件描述符是否被硬限制（常见于容器或某些 PaaS）
• 别信 php -r "var_dump(function_exists('proc_open'));" 输出 true 就代表能用——函数存在 ≠ 能 fork 出进程

快速添加 1GB Swap 解决 fork 失败

大多数 VPS、轻量云或 Docker 容器默认没配 Swap，而 Composer 在并发下载/解压时会触发大量 fork，1GB 物理内存根本扛不住。执行这三步就行：

• dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
• mkswap /var/swap.1
• swapon /var/swap.1

注意：swapon 可能报 insecure permissions，补一句 chmod 600 /var/swap.1 再重试。加完后 free -m 应显示 Swap 已启用，再跑 composer install 基本就过了。

控制 Composer 并发，避免二次压垮内存

Swap 是兜底，但治标不治本。Composer 默认并行拉包，小内存机器上很容易再次触发 fork 失败。强制串行最稳：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 加 --max-jobs=1：彻底禁用并发，适合 1GB 及以下内存环境
• 配合 --prefer-dist：跳过 git clone，只下 zip 包，减少进程启动次数
• 避免 composer update：它比 install 更吃内存；线上部署一律用 install + 锁定 composer.lock

示例命令：composer install --prefer-dist --max-jobs=1 --no-scripts --no-plugins。其中 --no-scripts 和 --no-plugins 虽不解决 fork，但能省下几 MB 运行时内存。

为什么本地构建上传 vendor 更可靠

在目标服务器上硬扛 Composer，本质是在资源受限环境下做高开销操作。真实项目中，90% 的线上部署卡点不是 Composer 本身，而是环境不可控：

• 某些云平台（如部分 Serverless PHP 环境）连 exec 都被禁，COMPOSER_DISABLE_FUNCTIONS=1 直接失效
• Docker 构建阶段有足够内存，但运行时容器被 memory limit 严格限制，fork 必败
• Swap 在容器里未必能生效（取决于 cgroup v1/v2 和 root 权限），本地构建则完全规避该问题

真正省事的做法：开发机 composer install --optimize-autoloader，把整个 vendor/ 打包上传，删掉 composer.json 和 composer.lock（除非需要后续更新）。这比调半天服务器参数更接近“一次搞定”。