Laravel应用通过Vapor部署AWS Lambda遇包大小超限问题求助

这种情况我之前帮团队排查过类似问题——明明代码改动极小，却突然触发Lambda的包大小限制，而且只在特定分支出现，确实挺头疼的。给你几个具体的排查方向，按优先级来：

• 对比develop与正常分支的构建产物差异
  先在本地执行 vapor build --local 分别构建develop和staging分支，然后用 du -sh 查看生成的zip包大小，确认是不是develop的包确实更大。如果差异明显，解压两个zip包对比内容：

  • 看看是不是develop分支打包了dev依赖（比如phpunit、laravel-debugbar这类），检查vapor.yml里develop环境的构建命令有没有带--dev参数；
  • 对比vendor目录大小，有没有某个依赖在develop分支版本更大；
  • 检查storage或public目录，是不是develop分支有大日志、测试文件或临时资源被误打包。

• 清理构建缓存与残留文件
  GitHub Actions和Vapor CLI都会用缓存加速构建，但有时候缓存会残留旧的大文件。试试：

  • 在GitHub Actions的deploy步骤中加入清理命令：rm -rf vendor node_modules storage/logs/*，然后重新安装依赖；
  • 用Vapor CLI构建时加--no-cache参数：vapor build --no-cache，强制跳过缓存重新构建；
  • 检查项目根目录有没有临时生成的大文件（比如备份、测试数据）被纳入了版本控制，导致打包时被包含。

• 检查分支的依赖锁文件差异
  即使没手动引入新库，也可能因为composer.lock或package-lock.json的差异导致依赖包大小变化：

  • 对比develop和staging分支的锁文件，看看有没有依赖版本被更新，尤其是大体积的依赖（比如某些图片处理、PDF生成库）；
  • 执行composer install --no-dev在develop分支重新安装生产依赖，再构建试试，确认是不是dev依赖导致的体积膨胀。

• 核对Vapor环境配置差异
  检查vapor.yml中develop环境的专属配置：

  • 有没有开启xray: true这类会额外打包扩展的功能？
  • 有没有配置files或directories字段，把不必要的大目录纳入了打包范围？
  • 对比其他环境，develop是不是启用了某些Lambda层或额外的资源集成，导致整体包大小超限。

• 确认AWS Lambda的实际限制
  别忘了Lambda的核心限制：zip格式的部署包压缩后不能超过50MB，未压缩的不能超过250MB。如果你的develop分支包刚好卡在阈值附近，哪怕是新增一个小文件都可能触发报错。可以用unzip -l查看zip包内容，找出体积最大的几个文件，针对性清理。

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