新EC2实例上Composer执行失败（Elastic Beanstalk环境）

这种老应用在云服务商机型淘汰后的部署踩坑我太熟了，尤其是Laravel 4这种停更多年的版本，和新的EB实例环境很容易出现兼容性问题。结合你描述的情况，我给你梳理下排查和解决的步骤：

第一步：先拿到完整的错误日志 #

你目前只看到了部署失败的开头，必须获取完整的部署日志才能精准定位问题：

• 登录AWS Elastic Beanstalk控制台，找到你的应用环境
• 切换到「日志」选项卡，选择「请求完整日志」，下载后重点查看CMD-AppDeploy/AppDeployStage0/AppDeployPreHook阶段的详细报错信息——比如是PHP版本不兼容、Composer安装依赖失败，还是权限问题？

针对Laravel 4 + EB的常见问题解决方案 #

1. 强制指定兼容的PHP版本 #

Laravel 4.2最高只支持PHP 5.6，而新的EB实例默认会用更高版本的PHP（比如7.4+），这是最常见的崩溃原因。你需要在项目根目录添加.ebextensions/php.config文件，强制指定PHP版本：

option_settings:
  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: document_root
    value: /public
  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: PHPVersion
    value: 5.6

⚠️ 注意：如果EB已经不再支持PHP 5.6，你可能需要基于旧实例创建自定义AMI，再用这个AMI来启动新实例。

2. 降级Composer版本适配Laravel 4 #

新版Composer已经不再兼容PHP 5.6和旧的composer.json语法，你需要在部署脚本里指定使用兼容的老版本Composer：
在项目根目录添加.ebextensions/composer.config：

container_commands:
  01_update_composer:
    command: export COMPOSER_HOME=/root && /usr/bin/composer self-update 1.10.26

1.10.x是支持PHP 5.6的最后一个Composer稳定大版本。

3. 修复Laravel目录权限 #

新实例的文件权限策略可能和旧实例不同，Laravel需要storage和bootstrap/cache目录有写入权限：
添加.ebextensions/permission.config文件：

container_commands:
  01_set_storage_permissions:
    command: chmod -R 775 storage bootstrap/cache
    cwd: /var/app/ondeck
  02_set_owner:
    command: chown -R webapp:webapp storage bootstrap/cache
    cwd: /var/app/ondeck

4. 确认环境变量完整迁移 #

Laravel 4依赖环境变量（比如APP_KEY、数据库连接信息）运行，新实例可能没有继承旧实例的配置：

• 进入EB控制台的「配置」->「软件」选项卡
• 检查所有必要的环境变量是否已经配置齐全，尤其是APP_KEY，没有它Laravel根本启动不了。

5. 检查Zip包的打包结构 #

有时候打包时会犯低级错误：

• 确保Zip包的根目录就是项目根目录（比如解压后直接看到app/、public/、.ebextensions/这些文件夹），而不是把项目放在一个子文件夹里
• 确认没有遗漏隐藏文件（比如.env、.ebextensions下的配置文件）

最后建议 #

先通过完整日志定位具体问题，再针对性解决——老应用的部署问题90%以上都是环境不兼容或者配置缺失导致的。如果还是解决不了，可以尝试在本地搭建PHP 5.6环境，先确保项目能正常运行，再打包部署到EB。

内容的提问来源于stack exchange，提问作者picus