Composer安装失败因PHP禁用了proc_get_status和proc_open函数，需在php.ini中移除这两个函数并重启PHP服务，二者必须同时启用才有效。
Composer安装失败提示“proc_get_status() has been disabled for security reasons”
这是 PHP 配置层面的函数禁用问题，不是 Composer 本身出错。当 proc_get_status 被禁用时，Composer 在执行脚本、调用 Git、解压包或运行 post-install-cmd 等操作时会直接中止，报错信息通常包含 “proc_get_status has been disabled” 或 “proc_open is disabled” —— 这两个函数常被一起禁用，且 Composer 依赖它们做子进程管理。
常见于共享主机、部分云虚拟主机（如某些阿里云轻量应用服务器默认配置）、或安全加固过的 PHP 环境。
确认当前禁用函数列表
先别急着改配置，先查清楚到底禁了哪些函数。运行以下命令定位真实限制来源：
php -i | grep disable_functions
输出类似：disable_functions => proc_open,proc_get_status,shell_exec,passthru。注意：这个值可能来自多个地方（php.ini、.user.ini、Web 服务器模块配置），优先级取决于 PHP SAPI 类型（CLI 和 FPM 可能读不同文件）。
立即学习“PHP免费学习笔记（深入）”；
- CLI 模式下 Composer 运行走的是
php -v对应的php.ini（可用php --ini查看路径） - 如果你在 Web 环境触发 Composer（比如通过网页界面安装插件），则要看 FPM 或 Apache 的 PHP 配置，和 CLI 不一定一致
- 某些环境（如宝塔、cPanel）会额外写入
.user.ini，该文件无法被php --ini显示，但对 Web 请求生效
修改 php.ini 解除 proc_get_status 限制
找到对应环境的 php.ini（CLI 下务必确认是 php --ini 输出的那个），搜索 disable_functions 行：
disable_functions = proc_open,proc_get_status,shell_exec
把 proc_get_status 和它依赖的 proc_open 从列表中删掉（注意逗号分隔格式，删完别留多余逗号）：
disable_functions = shell_exec
改完必须重启 PHP 服务才生效：
- FPM：运行
sudo systemctl restart php-fpm或sudo service php7.4-fpm restart（版本号按实际调整） - Apache：运行
sudo systemctl restart apache2 - CLI 场景（如本地开发）：无需重启，但要确保没其他层覆盖（比如 Docker 容器内需重建或重载）
验证是否生效：php -r "var_dump(function_exists('proc_get_status'));" 应输出 bool(true)。
为什么不能只开 proc_get_status？
单独放开 proc_get_status 没用 —— 它只是检查子进程状态的辅助函数，真正创建进程的是 proc_open。Composer 内部调用链是：proc_open → 启动 Git/PHP 子进程 → 用 proc_get_status 监控退出码。如果 proc_open 被禁，proc_get_status 根本没机会被调用。
也别试图只开 proc_open 而关 proc_get_status：Composer 源码里明确检查了这两个函数是否存在（见 src/Composer/Util/ProcessExecutor.php），缺一不可。
安全提醒：开放这些函数确实扩大攻击面（尤其在不受信代码可执行的场景），生产环境若必须启用，建议配合严格权限控制（如不给 Web 用户执行 Composer 权限，仅在部署脚本中使用 CLI 模式）。
真正麻烦的不是改 ini，而是有些托管环境根本不让你改主配置，或者改了被自动还原 —— 这时候得换思路：用预编译的 composer.phar 离线安装，或改用更受限但可行的 --no-scripts 模式绕过部分调用。
