composer 必须启用 proc_open 才能正常运行，因其执行 git clone、解压、脚本钩子等操作均依赖该函数；禁用会导致报错或卡死，需在 cli 和 web 对应的 php.ini 中从 disable_functions 里移除 proc_open。
proc_open 被禁用时，Composer 根本跑不起来——不是报错就是卡死，必须解禁才能继续安装或更新依赖。
为什么 Composer 非要 proc_open？
Composer 在执行 git clone、svn export、压缩包解压、脚本钩子（如 post-install-cmd）等操作时，底层依赖 proc_open 启动子进程。它不是可选功能，而是核心执行机制之一。
常见错误现象：proc_open(): fork failed - Cannot allocate memory 或直接提示 proc_open is disabled；Composer 卡在 Loading composer repositories 或 Installing dependencies 不动。
- PHP 7.4+ 默认未禁用，但很多共享主机、Docker 基础镜像（如
php:alpine）、宝塔/AMH 面板会默认禁用 - 禁用位置通常在
php.ini的disable_functions行里，和exec、shell_exec等一起列着 - 仅修改 Web 服务器（如 Nginx）的 PHP 配置不够，CLI 模式下运行 Composer 用的是另一个
php.ini（可通过php --ini查看）
怎么确认是 proc_open 被禁用了？
别猜，直接验证：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -r "var_dump(function_exists('proc_open'));"→ 返回bool(false)就是被删了函数 - 运行
php -r "print_r(ini_get('disable_functions'));"→ 看输出里有没有proc_open - 检查 CLI 和 Web 两套配置：分别执行
php --ini和php -r "phpinfo();"（或查看phpinfo()页面里的 Loaded Configuration File）
注意：有些环境（如 Docker）里 php --ini 显示多个 ini 文件，实际生效的是最后加载的那个，别只改了开头的。
解除禁用的实操步骤（分场景）
关键不是“打开”，而是“删掉那一行”——proc_open 本身没有开关配置项，它只受 disable_functions 控制。
- 找到对应
php.ini（CLI 下用php --ini，Web 下查phpinfo()输出） - 编辑该文件，搜索
disable_functions，把其中的proc_open删掉（注意逗号分隔，别留多余空格或逗号） - 如果是 Docker，别改宿主机的 ini，要在
Dockerfile里用sed或覆盖方式处理，例如：sed -i 's/proc_open,//g' /usr/local/etc/php/php.ini
- 重启 PHP-FPM 或 Web 服务（CLI 模式不用重启，但得确保改的是 CLI 用的那个 ini）
性能影响几乎为零；兼容性无问题——只要 PHP 版本 ≥ 5.0，proc_open 就是原生支持的。
绕不开 proc_open 的替代方案真的存在吗？
不存在真正可靠的绕过方式。有人试过：
- 换用
--prefer-dist强制走 zip 包 → 仍需解压，可能触发unzip外部命令，最终还是调proc_open - 提前下载 vendor 打包上传 → 临时可行，但后续
composer update或脚本钩子依然失败 - 用
composer install --no-scripts跳过钩子 → 只解决部分场景，且很多包（如 Laravel 的post-autoload-dump）依赖它生成自动加载器
结论很实在：不放开 proc_open，Composer 就不是完整可用的状态。安全顾虑可以靠限制执行目录、不开放用户输入、用最小权限运行 PHP 进程来缓解，而不是一刀禁函数。
最常被忽略的一点：改完 php.ini 后，忘记检查 CLI 和 Web 是否用了同一份配置——结果 Web 页面能跑，终端里 composer install 还是报错。
