答案是：服务器禁用proc_open和proc_get_status会导致Composer无法执行外部进程，从而在安装或更新依赖时失败。解决方法包括：有权限时修改php.ini启用函数；使用--prefer-dist优先下载ZIP包；配置allow-plugins减少插件错误；或本地安装后上传vendor目录实现离线部署。
当服务器禁用了 proc_open() 和 proc_get_status() 函数时，Composer 在执行某些操作（如安装包、更新依赖）时会报错，因为这些函数是 Composer 用来运行外部进程（例如 Git、tar 解压等）的关键函数。
问题原因
很多虚拟主机出于安全考虑，在 php.ini 中通过 disable_functions 禁用了 proc_open、proc_get_status、exec 等函数。而 Composer 需要调用这些函数来：
- 克隆 Git 仓库
- 解压压缩包
- 验证或运行脚本钩子
一旦这些函数被禁用，Composer 就无法正常工作。
解决方案一：启用被禁用的函数（推荐）
如果你有服务器控制权限（如 VPS、独立服务器或可修改 php.ini 的环境），最直接的方法是取消禁用这些函数：
- 打开 php.ini 文件
- 找到 disable_functions 配置项
- 删除 proc_open, proc_get_status
- 重启 Web 服务（如 Apache 或 PHP-FPM）
示例修改前：
disable_functions = exec,passthru,shell_exec,system,proc_open,proc_get_status修改后：
disable_functions = exec,passthru,shell_exec,system解决方案二：使用 allow-plugins 替代部分功能（有限支持）
新版 Composer 引入了插件机制和安全策略，但并不能绕过底层 PHP 函数限制。不过你可以尝试在 composer.json 中显式允许必要插件：
{
"config": {
"allow-plugins": {
"composer/package-versions-deprecated": true,
"symfony/flex": true
}
}
}
这不能解决 proc_open 被禁的问题，但有助于避免额外的插件拦截错误。
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
解决方案三：使用 ZIP 归档代替 Git 克隆
如果无法启用 proc_open，但仍需使用 Composer，可以强制使用 dist（发布包）而非 source（源码克隆）方式安装依赖：
- 大多数 Packagist 包提供 ZIP 下载链接
- Composer 可以直接下载并解压 ZIP，无需调用 Git
在命令行中添加参数：
composer install --prefer-dist
或者在 composer.json 中设置默认策略：
{
"config": {
"preferred-install": {
"*": "dist"
}
}
}
解决方案四：手动下载并离线安装
适用于完全无法使用 proc_open 的共享主机：
- 在本地运行 composer install --prefer-dist
- 将生成的 vendor 目录上传到服务器
- 确保 autoload.php 正常加载
这样就不需要服务器上运行 Composer 命令，彻底避开函数禁用问题。
临时绕过方法（不推荐）
有些用户尝试通过 PHP 的 FFmpeg 扩展或其它方式模拟 proc_open，但这不可靠且存在安全风险。强烈建议不要自行重写系统函数。
基本上就这些。能否使用 Composer 核心功能，关键在于服务器是否允许执行外部进程。最稳妥的方式是启用 proc_open 和 proc_get_status，或改用本地构建 + 上传 vendor 的部署流程。
