Composer在禁用proc_get_status的共享主机上会报错，可通过--no-scripts、--no-dev、--prefer-dist等参数规避，或本地安装后上传vendor目录。
这个问题通常出现在共享主机或某些受限环境里，PHP 的 proc_get_status() 函数被禁用，而 Composer 在执行某些命令（比如 create-project、install 或运行脚本时）会调用它来检查子进程状态，从而触发错误。
确认是否真的被禁用
先在服务器上运行以下代码，确认函数是否真的不可用：
<?php var_dump(function_exists('proc_get_status'));
如果输出 bool(false)，说明确实被禁用。常见于 cPanel、SiteGround、GoDaddy 等共享主机的默认 PHP 配置中。
绕过 proc\_get\_status() 的 Composer 配置方案
Composer 本身不提供直接关闭该函数调用的开关，但可以通过以下方式规避依赖它的行为：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 使用
--no-scripts参数跳过所有 post-install/post-update 脚本（这些脚本最常触发proc_get_status()） - 添加
--no-dev减少依赖数量和脚本执行概率 - 提前下载好 vendor 包（比如在本地完整安装后上传），避免在目标服务器上运行 install/update
- 改用
composer install --prefer-dist --no-interaction，优先走压缩包安装路径，减少对进程控制的需求
临时启用 proc\_get\_status()（仅限可修改 PHP 配置的环境）
如果你有权限修改 php.ini（如 VPS 或独立服务器）：
- 查找
disable_functions行，删掉其中的proc_get_status - 确保
proc_open和proc_close也没被禁用（它们是配套函数） - 重启 Web 服务（如 Apache/Nginx + PHP-FPM）使配置生效
注意：部分主机出于安全考虑硬性禁用这些函数，无法通过 php.ini 修改，此时只能走兼容方案。
替代工具或部署流程建议
在持续受限的环境中，可考虑调整开发工作流：
- 全部依赖在本地或 CI 环境中完成安装，打包
vendor/目录上传，跳过线上 Composer 执行 - 用
composer archive打包项目（需提前配置archive段落） - 改用更轻量的依赖管理方式（如手动 require 或使用静态 autoload），适用于小型项目
基本上就这些。核心思路是：不让 Composer 在禁用环境下“想查进程状态”，它就不会报错。
