“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=1024mkswap /var/swap.1swapon /var/swap.1
注意：swapon 可能报 insecure permissions，补一句 chmod 600 /var/swap.1 再重试。加完后 free -m 应显示 Swap 已启用，再跑 composer install 基本就过了。
控制 Composer 并发，避免二次压垮内存
Swap 是兜底，但治标不治本。Composer 默认并行拉包，小内存机器上很容易再次触发 fork 失败。强制串行最稳：
- 加
--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（除非需要后续更新）。这比调半天服务器参数更接近“一次搞定”。
