Composer 报错 proc_open 被禁用是因为 PHP 的 disable_functions 配置屏蔽了该函数，导致其无法执行 git、解压、运行子命令等依赖进程操作；需检查并修改 php.ini 中的 disable_functions 项，移除 proc_open 并重启 CLI 环境。
Composer 报错 proc_open 被禁用，本质是 PHP 运行时缺少执行外部进程的能力，不是 Composer 本身的问题，而是底层 PHP 配置限制了关键系统调用。
为什么 proc_open 被禁用会导致 Composer 失败
Composer 在安装、更新、脚本执行（如 post-install-cmd）等环节大量依赖 proc_open 启动子进程：调用 git 克隆仓库、解压 zip 包、运行 php 子命令、检查扩展等。一旦该函数被 disable_functions 屏蔽，就会直接报错：
PHP Fatal error: Uncaught Error: Call to undefined function proc_open() in /path/to/composer/vendor/symfony/process/Process.php
注意：错误里出现的路径是 Symfony Process 组件，但根因永远在 PHP 配置层。
确认 proc_open 是否真被禁用
别猜，直接验证。运行以下命令查看当前生效的禁用函数列表：
立即学习“PHP免费学习笔记（深入）”；
php -r "print_r(ini_get('disable_functions'));"
如果输出中包含 proc_open（可能还混着 exec、shell_exec、system 等），就坐实了问题。另外，也建议检查是否启用了 safe_mode（已废弃但某些老旧环境仍残留）或 open_basedir 过严导致子进程无法启动。
修改 php.ini 解除限制（需权限）
找到 Composer 实际使用的 PHP 配置文件（不是 Web 服务器用的那个）：
php --ini
输出类似：Loaded Configuration File: /etc/php/8.2/cli/php.ini —— 注意看 cli 路径，Composer 默认走 CLI SAPI。
编辑该 php.ini，定位到 disable_functions 行：
- 如果整行被注释（以
;开头），取消注释再删掉proc_open - 如果已启用，从值中移除
proc_open，注意逗号分隔格式，避免多出空格或遗漏逗号 - 改完必须重启 CLI 环境（不用重启 Web 服务），直接新开终端或运行
php -v验证是否生效
示例修改前：
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
修改后：
disable_functions = exec,passthru,shell_exec,system,popen
没有 php.ini 修改权限？换方案
共享主机或容器环境常锁死配置。此时不能硬改，得绕过：
- 用
composer install --no-scripts跳过需proc_open的脚本阶段 - 提前在有权限的机器上
composer install完成，把vendor/打包上传，跳过线上执行 - 若用 Docker，确保基础镜像（如
php:8.2-cli）未预设禁用proc_open；检查构建时是否执行了sed或ini-replace类操作 - 极少数情况可尝试用
php -d disable_functions="" composer.phar install临时覆盖，但多数托管环境会忽略该参数
真正麻烦的是那些把 proc_open 和 exec 一起封死、又不给配置权限的“安全加固”环境——这时候 Composer 基本不可用，得推动运维调整策略，而不是在代码层硬扛。
