1. 一次升级引发的连锁反应：为什么老站点迁移到 PHP 7 总出问题
手里维护着几个跑了五六年的 WordPress 站点，前阵子做服务器环境统一，把 PHP 从 5.6 拉到了 7.x，本以为是个常规操作，结果页面白屏、后台进不去、插件报致命错误，一连串问题砸过来。这件事让我意识到，WordPress 升级与 PHP 7 兼容性不是一个"点一下升级按钮"的动作，而是一整套需要提前排查、分步验证的工程。如果你手上也有老站点要迁移，或者正准备给客户做环境升级，这篇内容应该能帮你少走不少弯路。
先把话说清楚：这里讲的"兼容性"，本质上是代码层面的版本适配问题。PHP 7 相比 5.6 在语言层面做了大量清理，移除了一批过时特性，同时收紧了类型检查和错误处理机制。WordPress 核心本身从 4.9 之后对 PHP 7 的支持已经相当完善，真正卡脖子的往往是三类东西：年久失修的主题、停止维护的插件、以及主题 functions.php 里那些手写的旧式代码。这三者构成了绝大多数升级故障的来源。
适合谁来读？如果你是自己搭站点的个人站长，能看懂 PHP 报错信息、会用 FTP 或文件管理器改文件，那这篇可以直接照着做；如果你是给客户做运维的技术人员，文中的排查流程和回滚方案可以直接纳入你的标准作业流程；哪怕你只是刚接触 WordPress、想搞清楚"为什么升级会炸"，前面几节的原理拆解也能让你建立基本认知。我不打算讲太玄的东西，所有步骤都是我在实际环境里跑过、踩过坑之后整理出来的。
需要提前说明一点：不同站点的插件组合千差万别，没有任何一套方案能保证百分百无痛。所以整篇内容的思路是"先建立可控的测试环境，再逐步定位问题，最后带着回滚预案上线"，而不是让你直接在生产环境上动手。这个顺序很重要，后面会反复强调。
2. 升级前的整体设计与思路拆解
2.1 为什么不能直接在生产环境上升级
我见过太多人图省事，直接在线上站点后台点"更新"，然后眼睁睁看着首页变成一片空白。这种做法的问题在于：WordPress 的升级过程是不可逆的单向操作，一旦核心文件被覆盖、数据库结构被改动，想退回去就得靠备份。而很多人恰恰没有可用的备份，或者备份是几天前的，数据对不上。
正确的思路是把升级拆成三个阶段：备份与快照、隔离环境验证、生产环境灰度上线。第一阶段保证"出事了能退回去"，第二阶段保证"问题在没人的地方暴露"，第三阶段才是真正的切换。这三个阶段里，第二阶段最耗时也最有价值，因为绝大多数兼容性问题都会在这里现形。
具体到 PHP 版本这件事，还要多一层考虑：PHP 7 内部又分 7.0、7.1、7.2、7.3、7.4 几个小版本，每个小版本的弃用策略不同。比如 7.2 移除了create_function，7.4 对数组下标访问的可空性收紧了检查。所以"升到 PHP 7"这个说法太笼统，实际选哪个小版本，取决于你的 WordPress 核心版本和插件生态。我的经验是：WordPress 5.6 以上配 PHP 7.4 是比较稳的组合，再往上到 PHP 8 就要更谨慎，因为 PHP 8 的改动幅度比 7.x 内部大得多。
2.2 兼容性问题的三大来源与优先级判断
排查之前先建立一张"嫌疑地图"，能大幅提升效率。根据我处理过的案例，问题来源大致按出现频率排序如下：
| 来源 | 典型表现 | 排查难度 | 处理方式 |
|---|---|---|---|
| 停止维护的插件 | 启用即白屏、后台报致命错误 | 低 | 找替代品或打补丁 |
| 老旧主题的 functions.php | 特定页面报错、功能失效 | 中 | 逐段注释定位 |
| 核心版本过旧 | 升级后数据库报错 | 中 | 先升核心再升 PHP |
| 服务器扩展缺失 | 上传失败、图片处理异常 | 低 | 补装扩展 |
| 自定义代码片段 | 偶发性报错 | 高 | 日志追踪 |
这张表的用法是：先按"低难度"逐项排除，再处理"高难度"的。因为低难度问题往往一改就好，能快速缩小范围；而自定义代码的问题需要日志和时间，放在后面处理更合理。
还有一个容易被忽略的点：升级顺序。很多人以为先升 PHP 再升 WordPress，其实反了。正确的顺序是先把 WordPress 核心升到较新版本（它对高版本 PHP 的兼容性更好），再升 PHP。如果核心版本太旧（比如还在 4.x），那第一步应该是升核心，而不是动 PHP。这个顺序搞反，等于让旧代码去适配新解释器，故障率会高很多。
2.3 测试环境的搭建原则
隔离环境不需要多豪华，一台能跑起来的最低配置机器就够。我通常的做法是：复制一份生产数据库和文件到测试目录，用独立的域名或子目录访问，PHP 版本单独指定。这样测试环境和生产环境的数据一致，但互不影响。
这里有个实操细节值得说：复制数据库的时候，记得把站点地址（siteurl和home）改成测试环境的地址，否则 WordPress 会自动跳回生产域名，测试根本没法进行。改法有两种，一种是在数据库里直接改wp_options表，另一种是在测试环境的wp-config.php里临时定义常量覆盖。我一般用后者，因为改完不用再改回来，删掉常量就恢复了。
测试环境搭好后，先别急着升 PHP。先在当前 PHP 版本下把 WordPress 核心升到目标版本，确认站点正常，这一步能排除掉核心升级本身带来的问题。核心稳定了，再切 PHP 版本，问题就只可能出在 PHP 兼容性上，排查范围一下子清晰了。
3. 核心细节解析与实操要点
3.1 备份到底要备哪些东西
"备份"这两个字说起来简单，但真正能救命的备份，必须包含三样东西：数据库完整导出、网站文件完整打包、当前 PHP 与 WordPress 版本号记录。前两样是恢复用的，第三样是回滚时确认环境用的。
数据库导出我习惯用命令行，因为比后台插件导出更彻底，也不会因为超时中断：
mysqldump -u 用户名 -p 数据库名 > backup_$(date +%Y%m%d).sql导出后一定要验证文件大小是否合理，太小说明导出失败。文件打包同理，用tar压缩整个站点目录，排除掉缓存和日志目录能显著减小体积：
tar -czf site_backup.tar.gz --exclude='wp-content/cache' --exclude='*.log' /path/to/site注意：备份文件不要放在网站根目录下，否则可能被直接访问下载，存在泄露风险。放到站点目录之外，或者加访问限制。
版本号记录这一步很多人省掉，结果回滚时忘了原来是什么版本，装回去对不上。我的做法是在备份文件名里带上版本信息，比如site_backup_wp5.4_php5.6.tar.gz，一目了然。
3.2 用错误日志定位问题代码
PHP 7 对错误的处理比 5.6 严格得多，很多在旧版本下"默默忍受"的警告，在新版本里会直接变成致命错误。所以升级后第一件事不是看页面，而是打开错误日志。
在wp-config.php里加几行配置，把错误输出到日志文件而不是显示在页面上：
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);这样错误会写进wp-content/debug.log，页面不会因为报错信息暴露而显得乱七八糟。打开日志后，白屏问题基本都能定位到具体文件和行号。
读日志有个技巧：从最后一条往前看。因为致命错误会中断执行，最后一条往往就是根因，前面的可能只是连锁反应。看到类似Fatal error: Uncaught Error: Call to undefined function xxx()这样的信息，直接去搜这个函数名，基本能锁定是哪个插件或主题用了被移除的函数。
3.3 常见被移除特性的对照处理
PHP 7 移除或弃用了一批老函数和老写法，WordPress 生态里踩得最多的集中在下面几个。我把它们整理成对照表，遇到报错可以直接查：
| 旧写法（PHP 5.x 可用） | 问题 | 新写法 |
|---|---|---|
mysql_*系列函数 | PHP 7 已移除 | 改用$wpdb或mysqli |
create_function() | PHP 7.2 弃用、8.0 移除 | 改用匿名函数function(){} |
each() | PHP 7.2 弃用 | 改用foreach |
| 构造函数与类同名 | PHP 7 弃用 | 改用__construct() |
| 动态调用静态方法 | 严格模式下报错 | 显式声明static |
处理这些问题的原则是：能改代码就改代码，改不了就换插件。对于停止维护的插件，改代码意味着你要接手维护，成本可能比换一个替代品还高。判断标准很简单——如果这个插件在官方仓库里超过两年没更新，且作者已不响应，那就别修了，直接找替代方案。
3.4 主题 functions.php 的逐段排查法
主题的functions.php是重灾区，因为它经常被塞进各种自定义代码，而且没有版本管理。排查方法是二分法注释：先把文件后半部分整体注释掉，看问题是否消失；如果消失，说明问题在后半段，再对后半段二分；如果没消失，问题在前半段。这样几轮下来就能精确定位到具体几行。
注释的时候注意，PHP 里用/* */块注释要小心嵌套，如果原代码里已经有块注释，直接套会语法错误。稳妥的做法是用//逐行注释，或者临时把可疑代码复制到一个单独文件里测试。我一般会先把整个functions.php备份一份，改坏了直接还原。
提示：定位到问题代码后，不要急着删。先看这段代码是干什么的，很多时候它实现的功能可以用插件替代，或者用更现代的写法重写。直接删可能导致某个功能悄悄失效，比报错还难发现。
4. 实操过程与核心环节实现
4.1 从零搭建一个可回滚的测试环境
假设生产环境是 PHP 5.6 + WordPress 5.4，目标是升到 PHP 7.4 + WordPress 最新版。完整流程如下。
第一步，在生产环境做全量备份，包括数据库和文件，记录当前版本号。这一步做完之前，后面任何操作都不要开始。
第二步，在测试服务器上部署一份相同的代码和数据库。如果测试服务器和生產服务器是同一台，就用子目录加独立数据库的方式隔离。复制完成后，修改测试环境的wp-config.php，把数据库连接指向测试库，并临时加上：
define('WP_HOME', 'http://test.example.local'); define('WP_SITEURL', 'http://test.example.local');这样测试环境不会跳回生产域名。
第三步，在测试环境当前 PHP 版本下，先把 WordPress 核心升到目标版本。升级方式可以用后台一键更新，也可以手动替换核心文件（保留wp-content和wp-config.php）。核心升级后，逐页点一遍前台和后台，确认没有新问题。
第四步，切换测试环境的 PHP 版本到 7.4。切换方式取决于你的服务器管理面板，命令行环境下改站点配置里的 PHP 版本指向即可。切换后立刻访问首页，如果白屏，打开debug.log看报错。
第五步，按第 3 节的对照表逐个处理报错，每处理一个就刷新一次页面验证。全部处理完后，把前台主要页面、后台各菜单、表单提交、图片上传都过一遍，确认功能完整。
4.2 插件兼容性的批量筛查方法
插件多的时候一个个启用太慢，可以用一个取巧的办法：先把所有插件停用，然后分批启用。每批启用三到五个，刷新页面，正常就继续，报错就说明问题在这批里，再逐个细分。
更高效的做法是借助命令行工具批量检查插件的兼容性声明。很多插件在头部注释里写了Requires PHP字段，可以扫一遍：
grep -r "Requires PHP" wp-content/plugins/ | grep -v "7\."这条命令会列出所有声明要求 PHP 版本低于 7 的插件，这些就是重点怀疑对象。当然，声明归声明，实际能不能跑还得测，但至少能帮你把范围从几十个缩到几个。
对于确认不兼容又必须保留的插件，有两个选择：一是找作者的新版本或社区补丁，二是自己改。改的时候记住一个原则——只改报错的那一行，不要顺手重构。升级期间改动越少，出问题时越容易定位。
4.3 数据库层面的兼容性检查
PHP 版本升级本身不改数据库，但 WordPress 核心升级可能会改表结构。升级前建议检查一下数据库字符集和存储引擎，老站点常见的问题是还在用MyISAM引擎或者utf8而非utf8mb4字符集。
查看方法是在数据库里执行：
SHOW TABLE STATUS;看Engine列和Collation列。如果大量表还是MyISAM，建议在升级前转成InnoDB，因为新版本 WordPress 对InnoDB的支持更好，事务和崩溃恢复也更可靠。转换命令：
ALTER TABLE 表名 ENGINE=InnoDB;字符集方面，utf8mb4能支持完整的 Unicode 字符（包括一些特殊符号和表情），新装站点默认就是它。老站点如果还是utf8，可以在升级后统一转换，但要注意转换前备份，且转换过程中避免写入。
4.4 生产环境上线的灰度策略
测试环境全部通过后，生产环境的上线也不要一次性全量切换。我的做法是先切 PHP 版本，观察一段时间，再升核心（如果核心还没升的话），或者反过来，总之不要两个变量同时动。
切换时间选在访问低峰期，切换后立刻做一轮快速验证：首页、文章页、后台登录、发布一篇测试文章、上传一张图片。这几项覆盖了绝大多数核心功能，任何一项异常都立即回滚。
回滚方案要提前准备好：把 PHP 版本切回原版本，把备份的数据库和文件还原。回滚动作要能在十分钟内完成，所以备份文件要放在随手能拿到的地方，还原命令要提前写好。我一般会写一个简单的还原脚本，回滚时直接执行，避免手忙脚乱敲错命令。
5. 常见问题与排查技巧实录
5.1 白屏但日志里什么都没有
这是最让人抓狂的情况。白屏且无日志，通常意味着错误发生在 WordPress 加载之前，比如 PHP 本身启动失败，或者wp-config.php有语法错误。排查顺序是：先看服务器层面的 PHP 错误日志（不是 WordPress 的debug.log），再看wp-config.php是否有语法问题，最后检查 PHP 扩展是否缺失。
我遇到过一次，原因是测试环境的 PHP 7.4 没装mbstring扩展，WordPress 启动时直接挂掉，连日志都来不及写。补装扩展后一切正常。所以升级前核对 PHP 扩展清单这一步不能省，WordPress 必需的扩展包括mbstring、json、mysqli、curl、gd等。
5.2 后台能进但前台报错
这种情况说明核心和后台基本正常，问题出在前台渲染相关的主题或插件上。排查方法是临时切换到默认主题，如果前台恢复正常，问题就在原主题；如果还报错，就停用所有插件再试。
切换主题前记得记录当前主题名，测完切回去。有些主题切换后小工具和菜单位置会乱，切回后需要重新检查一遍布局。
5.3 上传图片失败或缩略图不生成
PHP 7 对图像处理扩展的版本有要求，老版本的gd库可能不兼容。表现是上传成功但缩略图不生成，或者上传直接报错。检查方法是看debug.log里有没有imagecreatefromxxx相关的报错，有的话就是gd扩展的问题。
解决办法是升级或重装gd扩展，确保它支持webp和jpeg。另外，PHP 7 对上传文件大小和内存限制的默认值可能和 5.6 不同，检查php.ini里的upload_max_filesize、post_max_size、memory_limit三个值，按站点实际需求调大。
5.4 常见问题速查表
| 现象 | 可能原因 | 快速验证 | 处理 |
|---|---|---|---|
| 整站白屏 | PHP 扩展缺失或配置语法错 | 看服务器 PHP 日志 | 补扩展、修语法 |
| 后台报致命错误 | 插件用了移除的函数 | 停用插件逐个测 | 换插件或改代码 |
| 前台样式错乱 | 主题 functions.php 报错 | 切默认主题 | 修主题代码 |
| 图片上传失败 | gd 扩展或上传限制 | 看 debug.log | 升级扩展、调限制 |
| 数据库连接错误 | 字符集或账号权限 | 手动连库测试 | 修配置、转字符集 |
| 固定链接 404 | 重写规则未刷新 | 后台保存固定链接 | 重新生成规则 |
这张表建议收藏，遇到问题先对号入座，能省掉大量瞎猜的时间。
5.5 几个踩过坑才明白的经验
第一个经验：升级前先禁用所有缓存插件和对象缓存。缓存会把旧版本的页面和数据结构留在那里，升级后读到旧缓存会报各种莫名其妙的错。升级完成、验证通过后再重新启用。
第二个经验：不要迷信"兼容 PHP 7"的插件标签。有些插件标着兼容，实际只在特定小版本下能跑。真正的验证标准是你自己的测试环境跑一遍，标签只能作为初筛参考。
第三个经验：升级后清理一下wp_options表里的临时数据。老站点跑久了，wp_options里会堆积大量_transient_开头的临时记录，升级过程中可能产生冲突。清理方法是在数据库里删掉过期的 transient，或者用命令行工具处理。这一步不是必须，但对老站点很有帮助。
第四个经验：保留一份升级前的完整环境快照，至少保留一到两周。有些兼容性问题不是立刻暴露的，可能过几天某个定时任务跑起来才报错。有快照在手，随时能对比排查。
6. 关于版本选择的一点个人判断
聊到最后，说说版本选择这件事。很多人纠结到底升到 PHP 7 的哪个小版本，我的实际体会是：跟着 WordPress 官方推荐的版本走最省心。官方每个大版本都会标注"推荐 PHP 版本"和"最低 PHP 版本"，按推荐值来，兼容性风险最小。目前主流站点用 PHP 7.4 是比较稳妥的落点，既享受了 7.x 的性能提升，又避开了 PHP 8 初期生态适配不足的问题。
至于什么时候该往 PHP 8 迁，我的判断标准是：当你的核心插件和主题都明确声明支持 PHP 8，且测试环境跑通全部功能时，再考虑迁移。不要为了追新而追新，生产环境的稳定永远优先于版本号的好看。
还有一个容易被忽略的长期问题：升级不是一次性任务，而是持续维护的一部分。这次升完 PHP 7，过一两年又要面对 PHP 8，所以借这次升级把站点的插件清单梳理一遍、把不再维护的依赖替换掉，比单纯解决眼前的报错更有价值。我在处理完兼容性问题后，会顺手整理一份"当前依赖清单"，标注每个插件的维护状态和替代方案，下次升级时直接拿出来对照，效率高很多。
这套流程跑下来，一个中等复杂度的老站点，从备份到生产上线，大概需要半天到一天的时间。时间主要花在测试环境的验证和问题定位上，真正切换的动作很快。慢就是快，前期排查做得细，上线时才不会手忙脚乱。
