WordPress 升级后白屏、后台按钮点不动、页面样式全乱——这三种情况占了升级故障的九成。这篇文章给出按顺序执行的排查步骤，绝大多数情况在十分钟内能定位。
一、升级前必须做的两件事
如果还没升级，先做这两步，出了问题能十分钟内恢复原状：
- 备份数据库。用 phpMyAdmin 导出，或者主机面板的备份功能。别只备份文件——升级出问题八成在数据库结构上。
- 确认 PHP 版本。后台 → 工具 → 站点健康 → 信息 → 服务器，看 PHP 版本。WordPress 6.x 建议 PHP 8.0 以上，7.4 已经停止安全支持。
已经升级出问题了？直接跳第二节。
二、白屏 / HTTP 500：先拿到真实错误
WordPress 默认不显示错误，所以白屏看不到原因。打开调试模式：
编辑 wp-config.php，把 WP_DEBUG 那行改成：
|
1 2 3 4 |
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'SCRIPT_DEBUG', true ); |
这样错误不会显示在页面上（避免暴露给访客），而是写进 wp-content/debug.log。刷新一次页面，然后看这个文件末尾：
|
1 |
tail -50 wp-content/debug.log |
注意：排查完记得把 WP_DEBUG 改回 false，否则日志会越滚越大，而且可能泄露路径信息。
连 wp-config.php 都进不去的情况
如果 FTP/SSH 都没有，只能用主机面板的文件管理器。如果连这个都没有，联系主机商。
常见 500 错误对照
| 日志里的关键词 | 原因 | 处理 |
|---|---|---|
Allowed memory size exhausted |
内存不足 | wp-config.php 加 define('WP_MEMORY_LIMIT', '256M'); |
Call to undefined function |
PHP 版本太低，或文件不完整 | 升 PHP 版本；重新下载 WordPress 覆盖 wp-includes/ |
Cannot redeclare function |
插件或主题重复定义函数 | 禁用最近装的插件 |
syntax error, unexpected |
某个 PHP 文件被改坏了 | 看日志里的文件路径和行号，还原那个文件 |
Maximum execution time exceeded |
升级卡在数据库更新 | 见第六节 |
三、后台能进，但按钮点不动
典型表现：点「添加媒体」没反应、可视化/文本切换失效、菜单的「显示选项」点不开、文章列表的批量操作下拉打不开。
这类问题几乎都是 JavaScript 冲突，不是 PHP 错误。因为页面能正常渲染，只是 JS 没跑起来。
第一步：看控制台
F12 → Console，刷新页面，看有没有红色的报错。常见的有：
jQuery is not defined—— jQuery 没加载，或加载顺序错了$(...).xxx is not a function—— jQuery 版本不兼容（主题用了老 API，新 jQuery 移除了）Uncaught SyntaxError—— 某个 JS 文件被改坏，或压缩时出错Failed to load resource: 404—— 某个 JS 文件路径变了
第二步：排除插件
把所有插件停用，看问题是否消失。如果消失，逐个启用，启用到哪个出问题就是它。
后台点不动时怎么停用插件？两种办法：
办法 A：用 FTP 把 wp-content/plugins 整个目录改名成 plugins-off，WordPress 会自动停用所有插件。排查完改回来。
办法 B：直接改数据库，把 wp_options 表里的 active_plugins 值改成一个空数组：a:0:{}。
第三步：一个真实的历史案例
WordPress 4.3.1 发布时，简体中文语言包有一个翻译字符串损坏，导致后台「添加菜单项」区域的 JS 报错，整片 UI 点不动。当时的解决办法是替换 wp-content/languages/admin-zh_CN.mo，或者在主题里挂一个 filter 覆盖那条翻译。
这个具体 bug 早就修了，但它揭示的排查方向一直有效：如果核心功能失效、控制台报的是翻译相关的错、而且只在中文本地化环境出现，去检查语言包。
现在的做法：
- 后台 → 更新 → 重新安装「简体中文」语言包
- 或者用 FTP 删掉
wp-content/languages/下的.mo文件，让 WordPress 重新下载
临时应急可以在 wp-config.php 里把语言切回英文，确认问题是否由本地化引起：
|
1 |
define( 'WPLANG', 'en_US' ); |
四、页面样式全乱 / 布局错位
升级后样式乱了，按这个顺序查：
- 清缓存。主题缓存、插件缓存、CDN 缓存、浏览器缓存，四层都可能。先按 Ctrl+Shift+R 强刷，再清 CDN。
- 看是不是 CSS 合并压缩导致的。很多主题有「合并 CSS/JS」选项，升级后合并出的文件可能包含旧代码。关掉合并功能试一次。
- 检查子主题。父主题升级后如果改了 HTML 结构或 CSS 类名，子主题里覆盖的样式就会失效。这是升级后样式错位最常见的原因。
- 看是不是插件注入的样式失效了。比如页面构建器（Elementor、WPBakery）升级后旧版块需要重新生成 CSS，后台一般有「重新生成 CSS」的按钮。
五、插件冲突的标准定位法
前面提过「全部停用再逐个启用」，实际操作时有个更高效的做法：
- 停用一半插件，看问题是否消失
- 消失 → 问题在停掉的那一半里，再对那一半重复步骤 1
- 没消失 → 问题在留用的那一半里，对那一半重复
这叫二分法，20 个插件最多 5 轮就能定位（而不是逐个试 20 次）。
如果不想在线上站折腾，装一个 Health Check & Troubleshooting 插件，它能在「不影响访客」的模式下模拟停用所有插件，只有你自己看到故障状态。
六、升级卡在「数据库更新」
后台提示「数据库更新需要执行」但点了没反应，或者转圈很久后报超时：
- 先去看
wp_options表里的db_version值，和wp-includes/version.php里的$wp_db_version对比。两个值不一致说明升级没跑完。 - 访问
https://你的域名/wp-admin/upgrade.php，手动触发升级 - 如果一直超时，多半是数据库太大或有慢查询。加长执行时间：
define('WP_MEMORY_LIMIT','256M');并让主机商临时放开max_execution_time - 还不行就用 WP-CLI：
wp core update-db，命令行不受 web 超时限制
七、回滚：出问题时怎么退回去
WordPress 没有「一键降级」。真要回滚，得靠升级前的备份：
- 恢复数据库（这一步必须在恢复文件之前，因为新版数据库结构可能不兼容旧代码）
- 恢复
wp-content目录（主题和插件） - 恢复 WordPress 核心文件（
wp-admin、wp-includes、根目录 php 文件）
顺序很重要：先库后文件。反过来的话，旧代码连上新库，可能因为字段缺失直接崩。
部分主机（如 SiteGround、Kinsta）提供自动备份和一键还原，这种情况下直接点还原最省事。
八、升级后的检查清单
- 首页、文章页、分类页、搜索结果页各打开一次
- 后台发一篇测试草稿，确认编辑器、媒体库、发布流程正常
- 移动端打开首页，确认没有布局错位
- 提交表单（评论、联系表单）测试一次
- 看
debug.log有没有新的 warning - 关掉
WP_DEBUG - 清一次全站缓存
九、预防：让下次升级不出事
- 别一有更新就点。小版本（如 6.7 → 6.7.1，安全修复）可以立即升；大版本（6.7 → 6.8）等一两周，让插件作者跟上。
- 先在测试站升。复制一份站点到子域名或本地（用 Duplicator、All-in-One WP Migration），在副本上升级验证，没问题再动线上。
- 关注插件兼容性。后台 → 工具 → 站点健康，能看到「插件与当前 WordPress 版本不兼容」的提示。
- 别用「一键升级全部」。核心、主题、插件分开升，出问题能立刻知道是谁引起的。
最后一句：升级出问题不可怕，可怕的是没备份。只要数据库和文件都有备份，任何升级故障都能退回去，最多损失半小时。