如何结合Git Pull使用Composer避免Laravel类未找到错误

我来分享几个生产环境验证过的最佳实践方案，帮你彻底解决部署时那几秒的类/服务找不到错误：

方案一：原子部署（最推荐，零 downtime） #

这是业内解决这类问题最稳妥的方式，核心逻辑是在离线环境完成所有部署准备，再瞬间切换到新版本，用户完全感知不到中间的依赖安装过程。具体步骤：

1. 在生产服务器上创建一个带时间戳的临时部署目录，避免冲突：

   mkdir /var/www/myapp-deploy-$(date +%Y%m%d%H%M%S)
   cd /var/www/myapp-deploy-$(date +%Y%m%d%H%M%S)
   

2. 拉取master分支的最新代码：

   git clone https://你的仓库地址.git .
   git checkout master
   

3. 安装依赖（一定要用install而非update，前提是你已经把composer.lock提交到版本控制，这样能保证生产依赖和本地测试完全一致）：

   composer install --no-dev --optimize-autoloader --no-interaction
   

4. 复制或软连生产环境的.env配置文件到新目录（避免重复配置）：

   cp /var/www/myapp/.env .
   # 或者用软链更方便：ln -s /var/www/myapp/.env .env
   

5. 执行Laravel的优化命令，确保配置、路由都缓存完成：

   php artisan config:cache
   php artisan route:cache
   php artisan view:cache
   

6. 切换生产环境的符号链接（假设你的Web服务器根目录指向/var/www/myapp）：

   # 先备份旧版本目录
   mv /var/www/myapp /var/www/myapp-old
   # 将新部署目录设为正式服务目录
   ln -s /var/www/myapp-deploy-$(date +%Y%m%d%H%M%S) /var/www/myapp
   

7. 验证新版本正常运行后，再删除旧目录（建议留1-2天备份更安全）：

   rm -rf /var/www/myapp-old
   

这个方案的优势是完全无服务中断，现在很多CI/CD工具（比如GitLab CI、GitHub Actions）都能一键实现这个流程，调整一次部署脚本就能一劳永逸。

方案二：预安装依赖+快速覆盖 #

如果暂时不想调整成原子部署流程，可以通过预安装依赖来压缩部署时的错误窗口：

• 在合并代码到master之前，先在生产服务器的临时目录拉取待合并的分支，执行composer install --no-dev，把vendor目录缓存起来
• 合并代码到master后，拉取最新代码到生产正式目录，直接将缓存的vendor目录覆盖过去
• 接着执行composer dump-autoload --optimize和Laravel的优化命令

这种方式能把依赖安装的时间几乎降为零，不过要注意确保缓存的vendor目录和master分支的代码版本完全匹配，避免出现依赖不一致的问题。

方案三：延迟加载服务提供者（辅助优化） #

配合前面的方案，你可以把新增的服务提供者设置为延迟加载，让Laravel不在启动时就加载它们，而是在第一次使用时才初始化，从而减少启动时的类依赖检查：

1. 打开config/app.php，把新增的服务提供者从$providers数组移到$deferredProviders数组里
2. 确保该服务提供者类实现了DeferrableProvider接口，并且在provides()方法里返回它提供的服务类名
3. 部署时执行composer dump-autoload --optimize生成优化的自动加载文件

这个方法能缓解部分类找不到的问题，但不能完全替代前面的部署方案——如果你的代码里直接调用了新依赖的类（而非通过服务容器），还是可能在部署时出现错误，所以更适合作为辅助优化手段。

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