Composer 必须使用 proc_open，因其核心逻辑硬编码依赖该函数调用 git、unzip、php 等外部命令完成依赖安装；禁用后无法通过其他执行函数绕过，唯一可靠解法是修复 PHP 配置中误禁的 proc_open。
proc_open 被禁用时，Composer 无法执行 install/update 等依赖操作，根本原因是其内部大量依赖该函数调用系统命令（如 git、unzip、php）——禁用后会直接报错 proc_open() has been disabled for security reasons，此时不能靠配置绕过，必须换执行方式或修复环境。
为什么 Composer 非要 proc_open？
Composer 不是纯 PHP 实现的包管理器：它需要调用外部工具完成实际工作，比如：
- 克隆 Git 仓库时调用
git clone - 解压 zip 包时调用
unzip或7z - 运行脚本（
scripts）或插件时执行php some-script.php - 验证包完整性时调用
openssl或sha256sum
这些都通过 proc_open 启动子进程实现。禁用后，exec、shell_exec 等函数即使开启也无济于事，因为 Composer 核心逻辑已硬编码依赖 proc_open。
禁用环境下能用的替代方案
如果无法修改 disable_functions（例如共享主机、某些云函数环境），只能规避对 proc_open 的依赖：
- 使用
--no-scripts --no-plugins参数跳过需执行外部命令的环节（但部分包安装仍会失败） - 提前在有
proc_open的机器上运行composer install --no-dev --optimize-autoloader，然后把vendor/和composer.lock整体上传到目标环境 - 改用
composer install --prefer-dist --no-interaction，强制走压缩包分发路径（减少 git 操作），但前提是包提供 dist ZIP —— 并非所有私有库都支持 - 升级到 Composer 2.5+ 并启用
COMPOSER_DISABLE_NETWORK=1，可避免网络相关子进程，但不解决核心依赖问题
真正可靠的解法：检查并修复 disable_functions 配置
绝大多数情况下，proc_open 是被 PHP 配置误禁用的。排查路径如下：
- 运行
php -i | grep disable_functions查看实际禁用列表 - 检查
php.ini、.user.ini、htaccess（Apache）或php_admin_value[disable_functions]（Nginx + php-fpm）中是否显式写了proc_open - 若只是为安全禁用，可考虑只保留必要函数：
disable_functions = exec,passthru,shell_exec,system，但务必保留proc_open和proc_close - 重启 PHP 服务（如
sudo systemctl restart php8.1-fpm）后验证php -r "var_dump(function_exists('proc_open'));"返回bool(true)
很多运维同学以为删掉 proc_open 就更安全，其实它本身不执行命令，只是进程控制接口；真正危险的是 exec 类函数。盲目禁用 proc_open 反而让 Composer 回退到更不可控的 fallback 行为（比如尝试写临时 shell 脚本再执行），风险更高。
