WordPress 升级 PHP 前，先做这 7 项兼容性检查

为什么 PHP 升级前的检查值得单独做

WordPress 网站的 PHP 升级，看起来只是调整主机控制面板中的一个版本选项，实际上却同时改变了主题、插件和自定义代码运行的底层环境。一个网站首页能够成功显示，不代表 WooCommerce 定时任务、支付回调、会员登录或后台批量处理都能正常完成。

最容易被忽略的风险有两个：第一，升级后并不是所有错误都在首页暴露；第二，部分过时用法只产生警告或弃用提示，短期看不出问题，但可能在后续版本或业务流量下放大。

更可靠的方法，是把 PHP 升级当作一次有验收标准、能够回滚的小版本发布。

一、先盘点实际运行环境

升级前至少记录以下信息：

• 当前 PHP 版本、准备升级到的目标版本。
• WordPress 核心版本与最近一次更新日期。
• 正在启用的主题、子主题及其版本。
• 所有已启用插件，尤其是缓存、支付、表单、会员、翻译和定时任务插件。
• 自定义代码放置位置，例如主题 functions.php、mu-plugins、Code Snippets 或独立插件。
• PHP 扩展和主机服务依赖，如数据库驱动、图像处理、压缩、国际化组件。

不要只记“目前网站正常”。最好留下可复现的版本清单，以及至少一份升级前的后台、订单、表单或关键功能截图。

二、先做可恢复的备份，而不是只点击“备份成功”

完整备份必须覆盖网站文件与数据库，两者缺一不可。数据库可能保存文章、订单、配置和表单记录；文件系统则承载插件、主题、上传文件与自定义代码。

备份完成后，应额外确认三件事：

1. 备份文件真实存在，并且能独立下载或访问。
2. 文件大小与预期接近，存储位置不是仅有单点副本。
3. 能够在隔离环境中完成一次恢复演练，至少验证 WordPress 能启动并连接数据库。

如果数据库持续发生交易写入，升级窗口与备份时间之间的数据差异也要纳入回滚预案。电商或高频写入网站应规划维护窗口，不能简单地把昨晚备份当作随时可无损回滚。

三、优先检查已知的兼容性风险

不能把“插件最后更新日期较新”等同于“已通过目标 PHP 版本测试”。建议同时查看官方兼容声明、插件支持论坛和最近的修复日志。

代码层面可以重点审查：

• PHP 新版本明确不再支持的函数、语法或参数用法。
• 目标版本新增的弃用通知和更加严格的类型处理。
• 数组、字符串、空值等边界输入是否存在隐式类型依赖。
• 针对第三方依赖库的 PHP 版本约束，特别是 Composer 的平台要求。
• 没有自动测试覆盖的旧插件、长期未维护的主题，以及自行复制的历史代码片段。

静态检查的作用是缩小风险范围，不是保证零风险。有的错误只有特定插件组合、表单输入、语言环境或定时任务执行时才会出现。

四、建立一个接近生产环境的 Staging

理想的 Staging 应尽量与生产环境保持一致：相同的 WordPress 核心、插件/主题版本、数据库引擎和相关扩展。测试前对敏感数据做必要脱敏，并阻断会向真实用户发送的邮件、短信或支付请求。

在 Staging 升级到目标 PHP 版本后，不要只检查首页。建议按业务链路进行一次“小型回归测试”：

每项要有明确结果：通过、失败、未覆盖。特别关注后台日志中的 warning、deprecated、fatal error。测试完成后应清理或安全关闭调试日志，避免公开暴露路径、请求内容或敏感信息。

五、用真实日志验证，而不是只看工具界面

PHP 升级后的兼容性问题可能表现在慢查询、请求异常、队列停滞或后台某个按钮失效。

建议收集相同时间窗口中的 PHP 错误日志、Web 服务器日志及 WordPress 运行记录。出现错误时应定位到具体插件/主题、调用场景和可复现步骤，再确定是升级版本问题，还是原本就存在的缺陷。

不要为了让界面“看起来正常”而直接关闭所有错误记录。生产环境一般应避免将调试错误直接显示给访客，但在合适的保留期与权限控制下仍需保存必要的日志证据。

六、先决定回滚条件，再安排生产切换

升级执行前，可以设定明确的回滚阈值，例如：支付/订单链路失败、核心表单不可用、后台无法登录、持续出现关键 PHP 致命错误，或业务关键定时任务停止执行。

生产切换时，至少保留：

• 升级前的 PHP 版本和可恢复安装包或运行环境。
• 数据库与文件备份位置，以及责任人。
• 关键功能的快速测试清单。
• 日志观察窗口、问题记录位置和回滚决定条件。

出现问题时，先评估新旧环境的数据库兼容性和升级期间新增业务数据，再执行回滚；不要未经核对就直接覆盖一个仍有新订单或新表单数据的数据库。

七、升级后继续观察一段时间

当天的回归测试只是最基本的第一层验证。夜间备份、每日归档、内容同步、邮件摘要和排程任务经常不在人工测试时执行，因此至少还应观察一个完整的业务与定时任务周期。

这个周期结束后再归档升级记录，包括版本、变更时间、测试结果、已知风险和后续行动。这样下次升级会有清晰的依据，而不是从头排查。

可以复制的验收清单

• 已记录升级前 PHP / WordPress / 插件 / 主题版本
• 已完成文件和数据库备份，并验证可恢复
• 已检查插件、主题、依赖库的目标 PHP 兼容声明
• 已在 Staging 检查首页、后台、表单及业务关键链路
• 已检查 PHP 和 WordPress 错误日志
• 已验证定时任务或 Action Scheduler 队列
• 已制定升级窗口和明确回滚条件
• 已完成升级后观察并归档变更记录

技术参考

• PHP 官方迁移文档：https://www.php.net/manual/zh/appendices.php
• WordPress 开发文档：https://developer.wordpress.org/

延伸资源：作者参与维护的免费 WordPress PHP 兼容性静态风险排查工具 PHP Upgrade Risk Audit，参考地址：https://modelgain.com/products/php-upgrade-risk-audit/ 。静态检查只用于辅助发现潜在问题