根本原因是PHP环境未达标或关键功能被限制：需PHP≥8.1（Laravel10）、启用mbstring/openssl/ctype等扩展，禁用proc_open、open_basedir限制及root权限滥用。
绝大多数 Laravel 在 Linux 上安装报错，根本原因不是 Laravel 本身有问题，而是 PHP 环境没达标或被限制了关键能力。 直接看具体问题点更省时间。
PHP 版本和扩展不满足最低要求
Laravel 10 要求 PHP ≥ 8.1，Laravel 9 要求 ≥ 8.0 —— 很多服务器默认装的是 PHP 7.4 或更低，php -v 一查就露馅。即使版本够，以下扩展也必须启用：
-
mbstring、openssl、ctype、tokenizer、xml、json、pdo、zip - Ubuntu/Debian：运行
sudo apt-get install php-mbstring php-openssl php-ctype php-tokenizer php-xml php-json php-pdo php-zip - CentOS/RHEL：用
sudo yum install php-mbstring php-opcache php-openssl php-ctype php-tokenizer php-xml php-json php-pdo php-zip - 改完
php.ini后别忘了重启 PHP-FPM 或 Apache：sudo systemctl restart php-fpm
PHP 禁用函数拦住了 Laravel 启动
Laravel 的 Artisan 命令、队列、文件生成等依赖 proc_open 和 proc_get_status。宝塔、aapanel、LNMP 一键包常默认禁用它们，报错现象包括：
Call to undefined function proc_open()-
php artisan key:generate卡住或报错 -
composer create-project提示 “command not found” 或直接失败
解决方法是编辑 /etc/php.d/www.conf（或你的 PHP-FPM pool 配置），删掉或注释掉这行：
disable_functions = proc_open,proc_get_status,passthru,...
保存后执行 sudo systemctl restart php-fpm。
open_basedir 限制导致 vendor/autoload.php 找不到
这是线上部署最隐蔽的 500 错误来源之一。Nginx 配置里如果加了类似这样的语句：
fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";
会导致 Laravel 的 public/index.php 无法加载 vendor/autoload.php（它在上层目录），报错：
Warning: require(): open_basedir restriction in effect. File(/www/wwwroot/myapp/vendor/autoload.php) is not within the allowed path(s)
解决方式有二：
- 在 Nginx vhost 配置中删除或注释掉含
open_basedir的fastcgi_param行 - 如果是宝塔面板，直接进网站设置 → “防跨站攻击（open_basedir）” → 关闭勾选
改完务必 sudo nginx -t && sudo systemctl reload nginx。
权限与用户身份引发的静默失败
用 root 运行 composer create-project 或 php artisan 命令，常导致后续写入 storage/、bootstrap/cache/ 失败，但错误不明显。典型表现：
-
php artisan key:generate成功，但页面仍报 “No application encryption key has been specified” -
storage/logs/laravel.log权限为root:root，而 Web 服务器（如 www-data 或 nginx 用户）无权写入
正确做法是：用非 root 用户操作，然后统一设权：
chown -R $USER:www-data /path/to/project<br>chmod -R 755 /path/to/project<br>chmod -R 775 /path/to/project/storage<br>chmod -R 775 /path/to/project/bootstrap/cache
别图省事全用 777 —— 安全策略会拦截，且部分 SELinux 或 CloudLinux 环境下反而失效。
真正卡住人的往往不是某一个错误，而是多个限制叠加：PHP 版本低 + 缺扩展 + proc_open 被禁 + open_basedir 锁死 + 用户权限混乱。建议按顺序逐项验证，每改一项就跑一次 php -m | grep mbstring 或 php -i | grep disable_functions，比盲目 chmod 更可靠。
