网站运行多年突然要升级 PHP 版本，最怕的不是升级本身，而是升级完成后页面白屏、功能异常，却不知道从哪里查起。这篇文章解决”PHP 版本升级前后到底要检查什么、出问题怎么退回去”的问题，帮助你把升级从一次冒险变成一套可验证、可回退的标准流程。无论是运行在虚拟主机还是 VPS（虚拟专用服务器）上的 WordPress 或自建站点，都可以按这份清单操作。
一、升级前：先确认当前环境与版本差异
动手之前先弄清两件事：现在跑的是什么版本，目标版本和自己差了几个大版本。跨一个大版本（比如 7.4 到 8.0）和跨多个大版本（5.6 直接到 8.x）的风险完全不同，后者几乎必然碰到废弃函数大面积报错。
先在服务器上确认当前版本：
php -v # 虚拟主机没有 SSH 时，可在网站根目录创建检查文件 # <?php echo phpversion(); >
确认版本后，重点核对官方的废弃清单：PHP 8.0 移除了 create_function、each() 等老函数；8.1 起给大量内部函数加入了非 null 参数的警告；8.2 把动态属性标记为弃用。把版本差异列成一张对照表，就知道后面排查要盯什么。如果网站是 WordPress，可以先在 WP CLI（WordPress 命令行工具）里跑一遍核心和插件的版本健康状况检查，很多插件页面会直接标注”兼容到 PHP 几”。
二、升级前：扫描代码里的兼容性隐患
人工翻代码效率太低，用静态分析工具扫描整个项目，几分钟就能列出所有疑似问题点。PHP 官方的兼容性检查工具支持指定目标版本：
# 安装 PHPCompatibility 规则集后对项目目录扫描 phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.1 /var/www/html --extensions=php
扫描结果里，ERROR 级别的项必须在升级前处理，WARNING 可以列观察清单。除了代码本身，还要检查三类外部依赖：第一是老版本第三方库，尤其是还在用 each()、create_function 的老旧插件；第二是 php.ini 配置项差异，比如 8.0 起默认不支持的部分动态属性写法；第三是扩展是否可用，新版本环境里 mysql_* 系列函数早已移除，必须确认项目已改用 mysqli 或 PDO（PHP 的数据库抽象层）。扫描完成后把问题清单存档，升级后逐条销号。修复代码期间可以顺带处理性能欠账，比如参考这篇 WordPress 速度优化指南，把拖慢页面的慢查询和插件问题一起清掉，避免升级后旧问题掩盖新版本的性能收益。
三、升级前：完整备份与灰度验证环境
备份是回退方案的地基。这一步要做的不只是文件备份，而是”文件 + 数据库 + 当前 PHP 配置”三样一起打包，并确认能恢复：
# 打包网站文件 tar -czf site-backup-$(date +%F).tar.gz /var/www/html # 导出数据库 mysqldump -u dbuser -p dbname > db-backup-$(date +%F).sql
备份完成后不要直接在生产环境升级。有条件的在测试环境装一份相同代码、切到目标 PHP 版本跑一遍核心流程：首页、登录、下单或表单提交、后台保存。共享虚拟主机用户可以用子目录建一套副本测试。验证时打开错误显示，任何 Fatal error 和 Deprecated 提示都记下来。测试环境跑不通的版本组合，就不要指望生产环境能蒙混过关。
四、升级时：切换版本并盯紧首轮报错
真正切换时选业务低峰期。虚拟主机通常在控制面板里直接选择 PHP 版本，VPS 上则切换 PHP-FPM（PHP 进程管理器）的套接字版本并重启服务：
# VPS 上把站点切到新版本 PHP-FPM 后重载 sudo systemctl reload php8.1-fpm # 确认网站实际运行版本 php -v
切换完成后立刻做三轮检查：第一轮打开首页和几个核心页面，确认没有白屏和 500 错误；第二轮看 PHP 错误日志，定位有没有升级前没扫到的报错；第三轮走一遍完整业务流程，比如提交一次表单、下一笔测试订单。日志位置一般在 /var/log/php*fpm*.log 或主机面板的错误日志入口。首轮发现的问题大多是废弃函数调用，按报错文件和行号逐条修复即可。如果切换后出现的是整站 502 或 504，多半不是 PHP 代码问题而是进程没有正常接管，可以对照这篇 Nginx 限流配置指南所属的服务器专栏系列排查网关层，再回头看 PHP 报错。
五、升级失败时：如何安全回退到旧版本
如果修复耗时太长、业务等不起，回退要果断。回退分两种情况：
- 页面级小问题：个别功能报错但站点整体可用，可以先保持新版本，把报错功能临时下线，同时修复代码。
- 大面积白屏或核心功能瘫痪：立即把 PHP 版本切回旧版本。控制面板切回旧版本通常几秒生效；VPS 上重新启用旧版本 FPM 并 reload。回退后清掉页面缓存和 PHP OPcache（字节码缓存），避免新旧版本字节码混用造成二次报错。
要明确一点：切回旧版本只是止损，代码兼容性问题依然存在。回退后把报错清单交给开发修复，修复完成并重新通过测试环境验证后，再择机二次升级。如果你想趁回退窗口把整站体检做扎实，可以按这篇 WordPress 数据库清理与查询优化检查数据库层面的隐患，很多”升级后变慢”其实混有数据表膨胀的问题。整套流程里，备份加回退方案的价值就在于把”网站瘫痪几小时”压缩成”切换几十秒”。
总结与行动建议
PHP 版本升级的稳妥路径是：确认版本差异 → 静态扫描兼容性问题 → 完整备份并搭建测试环境 → 低峰期切换并盯紧首轮报错 → 出问题按预案回退。每个环节都有明确的验证动作，不需要碰运气。我们的建议是：如果你的站点还在旧版本上，本周就先做前两步扫描和备份，摸清自己的兼容性底数；对于使用 Hostease 虚拟主机或 VPS 的用户，控制面板里可以直接切换 PHP 版本，回退同样只需一键，建议先把测试副本跑通再动生产站点。如果你需要进一步提升升级后的运行环境稳定性，可以参考这篇 服务器运维与优化专栏，把 PHP 版本管理和服务器配置巡检一起纳入日常维护。