Composer报错“proc_open failed”的根源是disabled_functions禁用了proc_open或proc_close；验证需检查function_exists('proc_open')及ini_get('disable_functions')，重点确认CLI与FPM配置差异，并仅放开必要函数。
Composer报错“proc_open failed”但PHP能正常执行命令？
这大概率是 disabled_functions 拦截了 proc_open、proc_close 或 shell_exec —— Composer 依赖这些函数启动子进程（如 git clone、unzip、php -v 检查），即使你手动运行 git 或 unzip 成功，Composer 仍会因无法调用底层函数而失败。
验证方法很简单：
php -r "var_dump(function_exists('proc_open'));"
php -r "var_dump(ini_get('disable_functions'));"
如果输出 bool(false) 或 proc_open 出现在 disable_functions 列表里，就是根源。
如何快速定位被禁用的函数是否影响Composer关键流程？
Composer 在不同阶段依赖不同函数：
立即学习“PHP免费学习笔记（深入）”；
-
proc_open：必须。用于执行git、hg、svn、unzip、7z等外部命令；也用于安全检测（如php -n -v） -
shell_exec：非必须但常见。部分插件或自定义脚本可能用它；Composer 自身在 fallback 场景下会尝试 -
exec/passthru：Composer 不直接使用，但某些第三方 installer（如hirak/prestissimo）可能间接依赖 -
system：基本不用，可忽略
重点检查 proc_open —— 它被禁用时，错误通常表现为：
[RuntimeException] Failed to execute git clone --no-checkout 'https://github.com/...' ...
而不是明确提示“function disabled”。
修改 php.ini 后 Composer 仍报错？注意 SAPI 差异
Web 服务器（如 Nginx + PHP-FPM）和 CLI 的 PHP 配置文件往往不同：
- CLI 使用：
php --ini查看加载的php.ini路径 - FPM 使用：
php-fpm -i | grep "Loaded Configuration File" - Apache mod_php：取决于
httpd.conf或.htaccess中的php_admin_value disable_functions
常见坑：
– 你改了 /etc/php/8.2/cli/php.ini，但 Composer 是通过 Webhook 触发的（走 FPM），FPM 的 php.ini 还没改
– Docker 环境中，docker exec -it app php -m 看的是容器内 CLI 配置，但 CI 流水线可能用的是另一个基础镜像
务必确认 Composer 实际运行时所用的 SAPI，并检查对应配置中的 disable_functions 值。
临时绕过 disabled_functions 调试 Composer？不推荐但有效
仅限排查，不可用于生产：
- 启动 CLI 时覆盖配置：
php -d disable_functions="" composer install - 或指定空值：
php -d disable_functions= composer update
如果此时 Composer 正常运行，就 100% 确认是 disabled_functions 导致的。但要注意：这样会绕过所有禁用项，包括潜在危险函数（如 eval、assert），切勿长期使用。
真正要做的，是精确放开 proc_open 和 proc_close，其余保持禁用 —— 多数安全策略只要求这两个函数可用，其他无需开放。
