Laravel应用Elastic Beanstalk部署：Composer依赖安装失败解决方案咨询

不是唯一方式，提交vendor文件夹只是临时 workaround，并非最佳实践，以下是更合理的解决方案：

方案一：移除源码中的vendor，强制EB执行Composer安装 #

1. 将vendor重新加入.gitignore，确保提交到仓库的源码包不包含该文件夹，避免EB直接跳过依赖安装步骤。
2. 创建或修改.ebextensions/02-composer-force-install.config文件，添加以下配置：

container_commands:
  01_clean_old_vendor:
    command: "rm -rf /var/app/current/vendor"
    ignoreErrors: true
  02_install_dependencies:
    command: "composer install --no-dev --optimize-autoloader --no-interaction"
    env:
      COMPOSER_HOME: /root

option_settings:
  - namespace: aws:elasticbeanstalk:application:environment
    option_name: COMPOSER_HOME
    value: /root

• ignoreErrors: true确保即使旧vendor不存在，部署也不会中断
• --no-dev跳过开发依赖（适合生产环境）；--optimize-autoloader优化Laravel自动加载性能

方案二：配置Elastic Beanstalk的Composer行为 #

利用EB内置配置项强制触发依赖安装：

1. 在EB环境的配置页面，找到aws:elasticbeanstalk:container:php:phpini命名空间，设置ComposerOptions为--no-dev --optimize-autoloader（按需调整）。
2. 添加环境变量COMPOSER_INSTALL_OPTIONS，值为--no-dev --optimize-autoloader，让EB部署时用指定参数执行composer install。

方案三：清理环境残留的旧依赖 #

如果实例上残留了之前部署的vendor文件夹导致EB误判：

• 直接重建Elastic Beanstalk环境：创建全新EC2实例，彻底清理旧依赖，适合测试环境或残留问题严重的场景。
• 或者在部署脚本中提前清理旧部署目录：

commands:
  01_clean_staging_dir:
    command: "rm -rf /var/app/staging/vendor"

为什么不推荐提交vendor到仓库？ #

• 仓库体积会快速膨胀，拉取/推送效率下降
• 开发环境与生产环境的依赖可能存在差异（如开发依赖无需部署到生产）
• 每次更新依赖都要本地执行composer install再提交，流程繁琐且易出错

内容的提问来源于stack exchange，提问作者A J Qarshi