先确认升级边界和回退目标

Laravel网站升级服务器配置，不能只看新服务器能否启动 PHP。应用依赖、PHP 扩展、数据库版本、队列与定时任务、文件存储及 Web 服务配置都要一起核对。稳妥的做法是先在与目标环境接近的测试环境完成兼容检查和备份恢复演练，再安排正式切换；如果新旧环境无法同时承载流量，就应预留维护窗口，并在上线前明确回退条件。

开始前，至少准备好当前服务器的系统与服务信息、应用代码及 composer.lock、.env、数据库和用户上传文件的可恢复备份，以及旧环境继续运行的能力。还要确定谁负责执行切换、谁负责业务验收，以及出现问题时由谁决定回滚。Laravel网站选择服务器配置时，版本和扩展应以项目依赖声明及实际检查结果为准，不要仅凭“服务器上有 PHP”就判断兼容。

一、建立现网基线，避免迁移后才发现差异

先记录当前环境，目标服务器也执行相同检查，便于逐项比较。以下命令适用于常见 Linux 环境；不同发行版的服务名称、包管理方式和配置路径可能不同，先核实实际值再操作。

php -v
php --ini
php -m
composer --version

检查 Web 服务和 PHP 进程管理器的实际服务名：

systemctl list-units --type=service --state=running

数据库版本应通过对应数据库客户端或管理工具查看，并记录字符集、时区、主要连接参数及是否使用独立的缓存、会话或队列服务。不要只比较数据库“大版本号”：应用实际使用的驱动、字符集、排序规则及 SQL 行为也可能影响兼容性。

在项目目录中核对依赖与 Laravel 状态：

composer validate
composer check-platform-reqs
php artisan --version
php artisan about

其中，composer check-platform-reqs 用于检查当前 PHP 环境是否满足已安装依赖声明的平台要求；如果目标机尚未安装依赖，可在部署目录安装锁定版本后再检查。php artisan about 并非所有旧版 Laravel 都提供，若命令不存在，可改用项目版本对应的诊断方式，不要因此直接认定应用不可用。

重点对照以下项目：

PHP 命令行和 PHP-FPM 可能使用不同版本或不同配置文件。即使 php -m 显示扩展齐全，也要确认 Web 服务实际调用的 PHP-FPM 已加载相同扩展。可用受控的测试请求检查 Web 进程环境，完成后立即移除测试文件，避免将环境信息暴露在公网。

二、确定升级路径：先兼容，再切流

升级服务器配置不一定要求同时升级 Laravel 应用。若目标是更换操作系统、PHP 或数据库，优先把应用代码与运行环境变化分开验证：先让现有代码在目标环境通过测试，再决定是否单独升级框架或依赖。一次同时改系统、PHP、Laravel 主版本和数据库，会让故障原因难以定位，也会显著增加回退复杂度。

推荐按以下顺序推进：

1. 在测试环境复刻目标 PHP、数据库及关键服务版本，部署当前代码和锁定依赖。
2. 执行兼容检查、自动化测试和关键业务流程验收。
3. 用备份数据进行恢复演练，验证文件、数据库和应用配置能共同恢复。
4. 在生产目标机预部署代码与依赖，但暂不接收正式流量。
5. 进入维护窗口，停止或暂停会写入数据的后台任务，完成最终备份和切换。
6. 验证健康检查、登录、读写、上传、队列和定时任务，再决定恢复正常流量。

应用代码依赖应依据锁文件安装，不要在生产机上临时执行 composer update。该命令会重新解析依赖，可能使生产环境与测试环境不同。部署时可使用：

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

此命令应在应用发布目录中执行，并确认 composer.lock 已纳入发布内容。若项目的部署方式要求从源码构建或依赖脚本有额外要求，应先在测试环境验证，再用于生产。

三、备份数据库、代码配置和用户文件

备份必须覆盖恢复所需的全部状态，而不只是数据库。至少确认以下内容：

• 数据库：业务表、Laravel 迁移记录，以及必要的数据库对象和权限信息。
• 用户文件：项目实际使用的上传目录或外部存储中的文件。
• 应用配置：.env、Web 服务配置、PHP-FPM 配置、队列与定时任务配置。
• 应用版本：当前发布代码、依赖锁文件和自定义部署脚本。
• 外部状态：若会话、缓存或队列数据保存在独立服务中，评估切换期间是否需要保留、清理或暂停处理。

.env 通常包含密钥和数据库凭据，应限制备份文件的访问权限，不能放入公开目录或提交到代码仓库。备份完成后，记录生成时间、文件大小和保存位置，并检查文件确实可读；仅看到命令执行结束，不代表备份可恢复。

MySQL 或兼容数据库可在确认客户端版本和权限后，按实际库名执行逻辑备份。下面是示例，需替换占位值；-p 会提示输入密码，避免把密码直接写入命令行历史：

umask 077
mysqldump --single-transaction --routines --triggers \
  -u DB_USER -p DB_NAME > /secure/backup/DB_NAME.sql

--single-transaction 适用于支持事务一致性快照的表类型；如果数据库包含非事务表或有特殊一致性要求，应采用经过验证的备份方案。PostgreSQL 等其他数据库应使用其匹配版本的备份工具，不要把上述命令直接套用。

上传文件可按项目实际目录归档。以下操作会读取指定目录并生成压缩包，不会删除源文件：

tar -czf /secure/backup/uploads.tar.gz -C /path/to/project storage/app/public

如果用户文件实际存放在其他目录或独立存储中，应对真实存储位置备份。备份数据库后若仍有用户写入，数据库与文件可能不再对应，因此最终备份应放在维护窗口内完成，或使用能够保证一致性的持续备份机制。

四、按窗口执行切换，控制写入和配置差异

维护窗口长度应由数据量、恢复演练耗时和业务低峰共同决定，不宜凭经验承诺固定时长。窗口开始前，先确认旧环境仍可用、目标环境部署完成、备份存储空间充足，并通知业务方暂停可能产生写入的操作。

切换过程可按以下顺序执行：

1. 开启 Laravel 维护模式，或在入口层暂时停止新请求。维护模式会影响用户访问，应提前告知并确认维护页可用。

   php artisan down

1. 暂停队列消费者及定时任务，避免切换期间旧、新环境同时处理同一任务。具体服务名取决于项目自身的进程管理配置，先通过服务管理器确认，不要猜测名称。对正在执行的任务，确认其完成、可安全重试或具备幂等处理能力。
2. 完成最终数据库和用户文件备份，记录时间与校验信息。备份未完成或不可读时，不进入下一步。
3. 将目标环境的数据库连接、应用密钥、缓存、会话、队列、邮件及文件存储配置逐项核实。复制 .env 时不要以模板文件覆盖现有配置；若更换应用密钥，可能导致既有加密数据或会话无法读取，除非已评估影响，否则应保持原密钥。
4. 安装锁定依赖，确认应用目录、storage 和 bootstrap/cache 由运行 PHP 的用户按需读写。只授予必要权限，避免用全局可写权限掩盖所有权问题。
5. 更新应用配置缓存，并清理只应在切换时清理的旧缓存。Laravel 配置缓存启用后，修改 .env 不会自动反映到运行配置，需重新生成缓存。

   php artisan config:clear
   php artisan config:cache

1. 如确需执行数据库迁移，先在测试环境验证迁移脚本，并确认可逆性及锁表、耗时影响。只有在备份确认有效、维护窗口足够且已评估回滚后果时，才在生产执行：

   php artisan migrate --force

生产迁移可能改变数据结构，migrate:rollback 并不等于恢复原数据；删除字段或转换数据后，简单回滚可能无法找回内容。高风险变更应采用分阶段兼容方案：先增加新字段并兼容旧代码，完成数据迁移与验证后，再另行清理旧结构。

1. 切换 Web 服务指向新发布目录或更新连接配置。若使用 Nginx，先检查配置语法再平滑加载；具体服务名需按系统实际安装确认。

   nginx -t

若检查失败，不要加载配置；修复后再次检查。PHP-FPM 服务也应按实际服务名核实状态，不能照搬其他机器的名称。

1. 执行健康检查和业务验收，确认通过后退出维护模式，并恢复队列和定时任务。

   php artisan up

Laravel 的 Web 根目录应指向项目的 public 目录，而不是项目根目录，以免源码、配置文件或 .env 被直接访问。变更 Web 配置时同时核对请求入口、静态文件处理、HTTPS 设置及 PHP-FPM 连接目标。

五、验证结果与判断是否回滚

切流后先检查低风险、可重复的项目，再进行真实业务写入。至少验证：

• 首页或健康检查返回预期状态，错误日志没有持续增加的新故障。
• 登录、会话、权限校验和关键只读页面正常。
• 在受控账号下完成一次可撤销的新增或修改，并确认数据库写入成功。
• 上传文件可写入、可读取，且存放位置符合预期。
• 队列任务能正常消费，失败任务有记录；定时任务没有在新旧环境重复执行。
• 监控和日志指向新环境，数据库连接、缓存及邮件等依赖没有异常。
• 维护模式关闭后，普通用户也能完成关键流程，而非只有服务器本机测试成功。

回滚应由明确条件触发，例如健康检查持续失败、关键业务写入异常、数据连接错误无法在窗口内修复，或错误率明显高于上线前基线。先判断故障属于代码、服务配置还是数据结构，低风险修复无法及时恢复时，再回退流量或恢复旧发布版本。

代码和 Web 配置可在保留旧版本的前提下切回旧发布目录，并恢复旧服务配置；加载配置前仍须执行语法检查。数据库回退则要单独决策：

• 若数据库结构未改变，且新环境没有产生需要保留的新写入，可切回旧环境继续服务。
• 若新环境已有业务写入，直接恢复切换前备份会丢失备份之后的数据。必须先评估这些写入是否需要保留，再决定数据同步、人工补录或恢复方案。
• 若迁移改变了表结构或数据格式，旧代码可能无法读取新数据。此时不能只切回代码，应使用预先验证的向后兼容方案，或按备份恢复，并明确恢复会影响哪些时间段的数据。

恢复备份属于有影响的数据库操作：执行前再次确认目标库、备份文件和恢复范围，确保当前数据另有留存；禁止在未核对库名时直接覆盖现有数据库。正式上线前应至少在隔离环境完成一次数据库与文件恢复演练，确认备份格式、字符集、权限和恢复顺序都可用。

六、容易遗漏的例外情况

有些项目把会话、缓存或队列放在数据库之外，切换时只备份数据库并不足够；应依据 .env 和实际服务配置确认状态在哪里。若使用本地文件会话或本地上传目录，切换服务器后也要确认文件是否同步完整。

另外，config:cache、route:cache 等优化命令是否适用于项目，取决于 Laravel 版本和应用写法。不要把所有缓存命令机械地放进部署脚本；先在目标环境验证命令可用及其副作用。迁移期间若同时运行新旧代码，还要确认两者都能读写当前数据库结构，不能假设“旧代码能启动”就代表可安全回退。

最容易漏掉的复核点通常不在首页，而在新环境的 PHP-FPM 扩展、上传文件权限、队列消费者和计划任务：它们可能在切流后才暴露问题。维护窗口结束前逐项确认服务运行状态、日志、数据库写入、文件访问和后台任务，并保留备份位置、版本号、切换时间及回滚决定记录。