Laravel部署至AWS Elastic Beanstalk后php artisan执行报错排查求助

以下是针对该问题的具体排查方向及操作建议：

1. 检查SSH会话与部署钩子的环境变量差异 #

AWS Elastic Beanstalk的postdeploy钩子会自动加载EB配置的环境变量，但SSH登录后的会话默认不会加载这些变量。Laravel的服务容器初始化高度依赖环境变量（如APP_ENV、APP_KEY、APP_DEBUG等），环境变量缺失或不一致会导致容器无法正确解析request门面。

• 操作：
  • 在SSH会话中执行 printenv，查看核心环境变量是否存在；
  • 手动加载EB环境变量：执行 source /opt/elasticbeanstalk/support/envvars，之后再尝试运行php artisan命令。

2. 清除不匹配的配置缓存 #

部署阶段执行config:cache时，缓存的是部署钩子环境下的配置。若SSH会话的环境变量与部署时不一致，缓存的配置会导致服务容器无法正确初始化request服务。

• 操作：
  • 在SSH会话中执行 php artisan config:clear 清除配置缓存；
  • 若清除后命令正常，说明是缓存与当前环境不匹配导致的问题，后续可避免在部署阶段提前缓存配置，或确保SSH会话加载一致的环境变量后再操作。

3. 验证文件权限 #

postdeploy钩子通常以Web服务器用户（如webapp）执行，而SSH登录用户一般是ec2-user，两者的文件权限可能不一致。bootstrap/cache目录下的缓存文件若权限错误，会导致Laravel无法正确读取容器配置。

• 操作：
  • 查看bootstrap/cache目录权限：ls -l bootstrap/cache；
  • 若所有者为webapp，可执行 sudo chown -R ec2-user:ec2-user bootstrap/cache storage 调整权限，之后再尝试运行命令。

4. 检查PHP CLI配置差异 #

EB的Web环境与CLI环境使用的php.ini可能存在差异，例如缺少必要扩展、配置项冲突等，会干扰Laravel的初始化流程。

• 操作：
  • 查看CLI环境的PHP配置：php -i | grep "Loaded Configuration File"；
  • 对比Web环境的PHP配置（可通过phpinfo()页面查看），重点检查extension加载情况、auto_prepend_file等配置是否存在差异。

5. 重新生成Autoloader并验证依赖 #

虽然已执行composer dump-autoload，但SSH会话的Composer环境可能与部署阶段不一致，导致Autoloader未正确生成。

• 操作：
  • 在SSH会话中执行 composer install --no-dev --optimize-autoloader，重新安装依赖并优化Autoloader；
  • 执行完成后再尝试运行php artisan命令。

6. 验证门面别名配置 #

Laravel的request是门面类，依赖config/app.php中的别名配置。若配置缓存时环境异常，可能导致别名未被正确加载。

• 操作：
  • 查看config/app.php中的aliases数组，确认是否存在 'Request' => Illuminate\Support\Facades\Request::class；
  • 若存在，清除配置缓存后重试；若不存在，添加该别名并重新缓存配置。

内容的提问来源于stack exchange，提问作者Chuck Le Butt