Laravel Forge 默认不支持零停机部署，因其采用单目录原地更新、无版本化发布结构、无原子切换机制，且迁移在代码加载后执行，易导致运行时异常。

Laravel Forge 本身不支持零停机部署，它没有内置的蓝绿部署或原子化切换机制；真正的零停机需依赖 Envoyer（已停止维护）或自行构建基于符号链接的部署流程。

Forge 的 deploy 脚本本质是顺序执行：拉代码 → 安装依赖 → 运行迁移 → 清缓存 → 重启服务。只要 php artisan migrate 有破坏性变更、或 composer install 耗时过长，就必然存在请求落到半更新状态的风险。

为什么 Forge 默认部署不是零停机

Forge 的部署流程在单目录下原地更新文件，git pull 和 composer install 会直接修改当前运行中的 current 目录（实际是软链指向的目录）。期间 PHP-FPM 可能加载到旧代码调用新数据库结构，或 Composer 正在写入 vendor/ 时被请求中断 —— 这些都会触发 Class not found、Undefined method 或 DB 异常。

• Forge 不创建版本化发布目录（如 releases/20250510123456）
• 不原子切换 current 软链接
• 不隔离 .env、storage/、bootstrap/cache/ 等共享路径
• 迁移命令默认在应用代码加载后执行，无法保证 schema 兼容旧代码

用 Forge 模拟零停机的关键改造点

你必须手动在 Forge 的「Deployment Script」中重写逻辑，模仿 Capistrano / Envoyer 的发布结构。核心是：分离代码与运行时、原子切换、迁移前置校验。

• 在 /home/forge/example.com/ 下手动维护 releases/、shared/、current 结构
• 每次部署生成带时间戳的目录（如 releases/20250510123456），完整 git clone + composer install --no-dev --optimize-autoloader
• 复制 shared/.env、shared/storage 到新 release 目录，再 php artisan storage:link
• 运行迁移前，先检查是否兼容（例如用 php artisan migrate:status --no-ansi | grep 'Ran' 判断是否已执行）—— 更稳妥的是把迁移拆到上线前人工确认阶段
• 最后用 ln -nfs releases/20250510123456 current 原子切换，再 sudo systemctl reload php8.2-fpm（非 restart）

cd /home/forge/example.com
RELEASE=$(date +"%Y%m%d%H%M%S")
mkdir -p releases/$RELEASE
git clone --depth=1 --branch=main https://github.com/you/app.git releases/$RELEASE
cd releases/$RELEASE
cp -r /home/forge/example.com/shared/.env ./
cp -r /home/forge/example.com/shared/storage ./storage
composer install --no-dev --optimize-autoloader --quiet
php artisan optimize:clear
ln -nfs /home/forge/example.com/releases/$RELEASE /home/forge/example.com/current
sudo systemctl reload php8.2-fpm

Envoyer 已停服，替代方案怎么选

Envoyer 在 2025 年底正式关闭服务，其域名和 API 全部下线。你现在无法再新建项目或触发部署。Forge 页面里残留的「Envoyer」选项只是历史 UI 未清理干净，点击会跳转 404。

• 不要依赖 Forge 控制台里的 Envoyer 集成按钮 —— 它早已失效
• 想继续用类似体验，可迁移到 Deployer（PHP 写的部署工具）或 CapRover（开源 PaaS，支持一键回滚+流量切换）
• 若团队熟悉 Laravel 生态，laravel-zero/deployer 是最平滑的替代：它复刻了 Envoyer 的发布目录、钩子、回滚逻辑，且可完全托管在自己服务器上
• 注意：任何方案都无法绕过「数据库迁移必须向前兼容」这一铁律 —— 零停机 ≠ 零风险，只是把风险窗口压缩到毫秒级软链切换瞬间

真正难的从来不是脚本怎么写，而是每次 php artisan migrate 前，你有没有确认新增字段加了默认值、旧代码读不到新列时会不会 crash、队列任务是

否跨版本消费失败。这些业务逻辑层面的兼容性，没法靠 Forge 或 Deployer 自动解决。