答案是proc_open(): fork failed - Cannot allocate memory本质为Linux内核按虚拟地址空间（VMA）总量拒绝fork，非物理内存不足；需禁用opcache.enable_cli、xdebug等扩展降低VMA，并调高vm.max_map_count或启用swap。
为什么proc_open(): fork failed - Cannot allocate memory不是真缺物理内存
这个错误本质是 Linux 内核在 fork() 时按虚拟地址空间（VMA）总量做判断，而非实际物理内存占用。PHP 主进程加载了 opcache、APCu、xdebug 等扩展后，会预分配大量共享内存段，导致虚拟内存 footprint 远超物理 RAM。哪怕你机器有 4GB 物理内存，PHP 进程 + 扩展的 VMA 可能被算作 6GB+，内核直接拒绝 fork。
-
opcache.enable_cli=0是关键：CLI 模式下 opcache 默认启用且预分配大块共享内存，关掉它能立竿见影降低 VMA - 禁用
xdebug：开发环境开着 xdebug 会让 Composer 内存占用翻倍，临时关掉再跑：php -d zend_extension= -d xdebug.mode=off composer install - 避免
apc.enable_cli=1或apcu：这些扩展在 CLI 下也会吃掉大量虚拟地址空间
怎么安全地绕过 PHP 内存限制而不改全局配置
永远优先用 php -d 参数临时覆盖，而不是去动 php.ini——因为 CLI 和 Web SAPI 的配置文件通常不同，你改错了地方根本没用。
- 最稳妥写法：
php -d memory_limit=-1 -d opcache.enable_cli=0 -d apc.enable_cli=0 composer install - 单位别写错：
2G可以，2GB在某些 PHP 版本下不识别；-1比具体数值更可靠 - 验证当前 CLI 配置路径：
php -i | grep "Loaded Configuration File"，确保你看到的是 CLI 实际加载的那个php.ini
容器或低配 VPS 上必须做的系统级干预
Docker 或 1GB VPS 常见问题不是 PHP 限得太死，而是内核参数太保守，尤其 vm.max_map_count 默认值（65530）不够 Composer 解压 zip 包时创建大量文件映射。
- 临时提高映射数：
sysctl -w vm.max_map_count=262144 - 加 swap 文件（非临时方案）：
sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile - 检查是否被 systemd 限制：
systemctl show --property=MemoryLimit composer.service，某些 CI 环境会静默设MemoryLimit=，它会干扰fork判断
composer install 卡住时先别硬刚内存，试试这些轻量操作
很多“内存不足”其实是伪命题——真正卡住的点常在插件、脚本或并发下载上，强行提内存反而掩盖真实瓶颈。
- 用
--no-scripts --no-plugins --no-dev组合：跳过所有 post-install-cmd、插件初始化和 dev 包解析，内存开销直降 70% - 强制单线程：
--max-jobs=1，避免多进程并发把虚拟内存撑爆 - 跳过 autoload 生成：
--no-autoloader，等装完再单独跑composer dump-autoload - 如果 lock 文件存在且可信，直接
composer install --no-update，它根本不走依赖求解器，几乎不耗内存
真正难搞的是那种既没 lock 文件、又含几十个私有 VCS 仓库的项目——这时候不是调参数能解决的，得人工拆包或换到更高配环境执行。
