必须从PHP配置层面修复，不能仅靠Composer配置；需在php.ini的disable_functions中移除proc_get_status和proc_open，并重启服务；若无权修改，则用--no-scripts等参数绕过依赖进程控制的脚本。
直接禁用 proc_get_status 会导致 Composer 在执行脚本、安装扩展、运行 post-install-cmd 等关键环节失败，错误通常表现为 Call to undefined function proc_get_status() 或 proc_open() has been disabled for security reasons。这不是 Composer 配置问题，而是 PHP 运行环境限制，必须从 PHP 配置层面修复。
确认被禁用的函数列表
在服务器上执行 php -i | grep disable_functions，查看输出中是否包含 proc_get_status、proc_open、exec、shell_exec 等。Composer 依赖 proc_open 启动子进程，而 proc_get_status 是其配套状态检查函数，两者常被一并禁用。
- 若仅禁用
proc_get_status而保留proc_open，Composer 可能部分工作但会在某些脚本（如 Laravel 的post-autoload-dump）中报错退出 - 共享主机常见做法是全局禁用整套进程控制函数，需一并处理
- 不要尝试用
dl()或反射绕过 —— PHP 8+ 已移除dl()，且禁用是 Zend 扩展级拦截，无法运行时启用
修改 php.ini 恢复函数（推荐方案）
找到当前 CLI 和 Web 使用的 php.ini 文件（运行 php --ini 查看路径），编辑后重启 PHP 服务。重点不是“启用”某个函数，而是从 disable_functions 列表中移除它。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 搜索配置项
disable_functions = - 删除其中的
proc_get_status和proc_open（保留其他如system、passthru仍可维持安全策略） - 若该行为空或注释状态，确认是否被其他配置文件覆盖（如
php-fpm.conf中的php_admin_value[disable_functions]） - 修改后务必执行
php -m | grep -i proc验证模块加载正常，并用php -r "var_dump(function_exists('proc_get_status'));"确认返回bool(true)
无权修改 php.ini 时的替代方案
适用于虚拟主机、部分 PaaS 平台（如早期阿里云虚拟主机、部分 cPanel 环境）。不能硬启函数，只能绕过依赖它的 Composer 行为。
- 使用
--no-scripts跳过所有钩子脚本：composer install --no-scripts，适合纯依赖下载场景 - 禁用自动 autoload 生成：
composer install --no-autoloader，后续手动运行php vendor/autoload.php或补全逻辑 - 改用静态安装方式：先在本地完整执行
composer install，打包vendor/目录上传，跳过远程执行环节 - 避免使用需要进程控制的插件，例如
hirak/prestissimo（已废弃）、composer-asset-plugin（Yii1 旧生态）等
php -r "echo extension_loaded('pcntl') ? 'pcntl loaded' : 'pcntl not loaded';"
注意：即使恢复了 proc_get_status，若系统缺少 pcntl 扩展（常见于 Windows 或精简版 Linux 容器），Composer 的并发安装（-j 参数）仍会退化为单线程，但核心功能不受影响。真正卡死的点永远是 proc_open 不可用 —— 其他都是衍生症状。
