根本原因是PHP中proc_open函数被禁用；需检查php.ini的disable_functions配置，移除proc_open和proc_get_status，确认CLI模式生效并重启PHP服务。
Laravel 10 安装时报错 “The Process class relies on proc_open, which is not available on your PHP installation”，根本原因是 PHP 环境中 proc_open 函数被禁用——这不是 Laravel 的 Bug，而是 Symfony Process 组件（Laravel 底层依赖）运行所必需的系统调用被主动拦截了。
为什么 Laravel 10 特别容易遇到这个错误
Laravel 10 默认启用更多基于进程的操作，比如：
- Artisan 命令自动执行 post-install 脚本（如生成 key、优化 autoload）
- Composer install/update 过程中调用 Git、php-cs-fixer 或其他 CLI 工具
- 本地开发时
php artisan serve启动内置服务器也间接依赖 Process 类 - 某些新包（如 Pest、Sail 相关工具）在安装阶段会触发子进程创建
怎么确认 proc_open 真的被禁用了
别只看报错，动手验证最可靠：
- 运行
php -r "var_dump(function_exists('proc_open'));"→ 输出bool(false)表示函数不存在 - 再跑
php -i | grep disable_functions→ 查看实际生效的禁用列表 - 用
php --ini确认 CLI 模式加载的是哪个 php.ini（注意：不是 Apache/Nginx 那个！）
常见禁用位置和修复方式
多数情况是以下三类环境默认禁用：
-
宝塔面板：PHP 设置里勾选了“禁用危险函数”，
proc_open和proc_get_status默认在黑名单中 → 进入 PHP 管理 → 禁用函数列表里取消勾选，重启 PHP-FPM -
Docker 官方镜像（如 php:8.2-cli-slim）：精简版常预设禁用 → 在 Dockerfile 中修改 php.ini：
RUN sed -i 's/disable_functions =.*/disable_functions = /' /usr/local/etc/php/php.ini -
共享主机/cPanel：无权改 php.ini → 只能绕过：本地
composer install --no-scripts --prefer-dist，上传完整vendor/，服务器上仅运行composer dump-autoload --optimize
修复后必须做的两件事
光改配置不够，漏掉任一都会继续报错：
- 确保 CLI 模式下生效：改的是
php --ini显示的 CLI 配置路径，不是 Web 模块的 - 重启对应服务：如果是 PHP-FPM，执行
sudo systemctl restart php8.2-fpm（版本号按实际调整）；Docker 则需重建容器
