WordPress 一更新就白屏？别重装——按这 5 层把站救回来

适用场景：刚更新了 WordPress 核心 / 插件 / 主题，前台变白屏、后台提示「出现了严重错误」，或整站打不开。
核心原则：先定位再动手。绝大多数「更新后挂站」是插件/主题兼容问题，不是数据库损坏，重装往往只会把问题拖得更久。
依据：本文步骤对齐 WordPress 官方文档（Common Errors、Debugging、Recovery Mode、wp-config），并结合宝塔等常见面板的可操作路径。

先别慌：这三种现象，通常还没丢数据

不要先做：重装 WordPress、清空数据库、随便覆盖上传「干净核心」却不备份。
建议先做：完整备份网站文件 + 数据库（宝塔：网站 → 备份；或主机面板一键备份）。有备份，后面每一步都可回退。

第 0 步：先看管理员邮箱（WordPress 恢复模式）

从 WordPress5.2起，站点发生致命错误时，系统会尝试向管理员邮箱发送一封「恢复模式」邮件，邮件里带有一次性登录链接。

1. 打开站点管理员邮箱（后台「设置 → 常规」里那个邮箱）。
2. 搜索关键词：WordPress、恢复、Recovery、fatal。
3. 若收到邮件：点击链接 → 登录后台 → 按提示停用出问题的插件/主题 → 点「退出恢复模式」。

说明：若站点依赖 SMTP 插件发信，而致命错误发生在该插件加载之前，邮件可能走服务器默认mail()，容易进垃圾箱或根本发不出去。收不到邮件不代表站没救，继续往下做第 1～5 层。

五层急救总览

按顺序做。哪一层让站点恢复，就停在那一层，再精细处理根因，不要五层一起乱改。

第 1 层：打开调试日志，让白屏「开口说话」

白屏往往是因为生产环境默认不把 Fatal Error 显示给访客。官方推荐：写入日志，但不在页面上展示错误（避免泄露路径与敏感信息）。

1.1 编辑wp-config.php

用宝塔「文件」或 FTP，打开网站根目录的wp-config.php。
在/* That's all, stop editing! Happy publishing. */（或「停止编辑」注释）上方加入：

define('WP_DEBUG',true);define('WP_DEBUG_LOG',true);define('WP_DEBUG_DISPLAY',false);@ini_set('display_errors',0);

注意：

• true/false不要加引号（加了引号会变成字符串，逻辑会错）。
• 修好之后，生产环境应改回WP_DEBUG为false，并删除或清空不再需要的debug.log。

1.2 复现一次错误

刷新刚才白屏的页面或后台地址，让错误再触发一次。

1.3 阅读wp-content/debug.log

打开wp-content/debug.log，从文件末尾往上看最近几行。重点找：

• Fatal error
• Uncaught Error
• Allowed memory size ... exhausted
• 路径里出现的wp-content/plugins/某插件/或wp-content/themes/某主题/

示例（示意）：

PHP Fatal error: Uncaught Error: Call to undefined function xxx() in /www/wwwroot/example.com/wp-content/plugins/bad-plugin/bad-plugin.php:42

路径指向哪个插件/主题，下一层就优先处理谁。

第 2 层：整站隔离插件（官方推荐做法）

WordPress 官方常见错误文档明确写过：无法进入后台时，可通过 FTP/文件管理器重命名插件目录，一次性停用全部插件。

2.1 一键停用全部插件

1. 进入wp-content/。
2. 把文件夹plugins改名为plugins_old（或plugins_disabled）。
3. 刷新前台与/wp-admin/。

若此时站点恢复 →几乎可以断定是插件冲突或某插件与新版本不兼容。

2.2 找出「罪魁」插件

1. 把目录名改回plugins。
2. 登录后台 →「插件」。
3. 一次只启用一个插件，每次启用后刷新前台与后台。
4. 哪个插件一启用就复现白屏/严重错误，就是问题源。

无法进后台时，也可在wp-content/plugins/里单独改名某个插件文件夹（例如contact-form-7→contact-form-7.off），效果等同停用该插件。

2.3 对问题插件怎么处理

第 3 层：临时切换默认主题

官方同样指出：白屏也可能是主题导致——尤其是刚换主题或主题刚更新之后。

3.1 能进后台时

「外观 → 主题」启用一套默认主题（如 Twenty Twenty-Four / Twenty Twenty-Five，以你服务器上已有的默认主题为准）。

3.2 进不了后台时

1. 进入wp-content/themes/。
2. 把当前正在用的主题文件夹改名，例如my-theme→my-theme.off。
3. WordPress 会回退到可用的默认主题（需确保至少有一套完整默认主题存在）。

若改主题后恢复 → 问题在主题或其子主题的functions.php、自定义代码、或与插件的组合冲突。可从备份恢复主题旧版本，或去掉最近加的自定义代码再测。

第 4 层：环境层——内存、PHP、伪静态规则

插件和主题都排除后仍异常，再查运行环境。这一层也要「有证据再改」，不要同时改十个地方。

4.1 PHP 内存耗尽

若debug.log出现Allowed memory size of ... bytes exhausted，可在wp-config.php的「停止编辑」注释上方增加（官方 wp-config 文档支持该常量）：

define('WP_MEMORY_LIMIT','256M');define('WP_MAX_MEMORY_LIMIT','256M');

说明：

• 这是让 WordPress尝试提高自身可用内存。
• 若主机/宝塔 PHP 面板把memory_limit锁死在更低值，还需在「软件商店 → PHP → 配置修改」里同步提高，否则常量可能无效。

4.2 PHP 版本不兼容

插件/主题更新后，常要求更高 PHP，或反过来：服务器升到 PHP 8.x 后，老插件报 Fatal。

建议：

1. 宝塔中查看当前 PHP 版本。
2. 对照问题插件/主题的说明，改到其支持的版本（常见可先试PHP 8.1 / 8.2）。
3. 每次只改一个大版本，改完立刻测首页与后台登录。

4.3.htaccess损坏（Apache）或伪静态异常（Nginx）

• Apache：若怀疑规则被写坏，可先把根目录.htaccess改名备份（如.htaccess.bak），再访问站点。若恢复，进入后台「设置 → 固定链接」点一次保存，让 WordPress 重新生成规则。
• Nginx（宝塔常见）：去站点 →「伪静态」，确认仍是 WordPress 规则，而不是空规则或其它程序规则。固定链接 404 与「更新后白屏」不是同一类问题，但更新过程中若有人改过伪静态，也会叠加故障，值得顺手核对。

4.4 还要看服务器错误日志

宝塔：网站 → 日志 → 错误日志；或 Nginx/Apache 错误日志。
有时 PHP-FPM / 权限 / open_basedir 问题只写在服务器日志里，不一定进debug.log。

第 5 层：回滚更新，并建立「以后不再裸更」的流程

5.1 回滚策略（务实版）

1. 先让站起来（第 2/3 层停用罪魁）。
2. 从备份或插件旧版本 zip回退该插件/主题。
3. 核心大版本若确认是核心导致：用备份整站回滚，或在维护窗口用官方发布包谨慎覆盖（务必先备份）。小安全更新一般仍建议保留，不要长期裸奔。

5.2 以后怎么更新更安全

一句话：自动更新不是敌人，毫无回退点的自动更新才是。

急救检查清单（可复制）

• 已备份文件 + 数据库
• 查过管理员邮箱的恢复模式链接
• 已开启WP_DEBUG+WP_DEBUG_LOG，且WP_DEBUG_DISPLAY为 false
• 已根据debug.log锁定插件或主题路径
• 已通过改名plugins验证是否为插件问题
• 已验证是否为当前主题问题
• 已处理内存 / PHP 版本 / 伪静态（仅在有证据时）
• 站点恢复后已关闭调试并清理debug.log
• 已对罪魁插件做回退或替换，并记录版本

常见误区

1. 一白屏就重装—— 多数情况下只是一个插件 Fatal，重装浪费时间且容易覆盖wp-config与上传目录配置。
2. 页面上开着WP_DEBUG_DISPLAY—— 生产环境会把路径、查询等信息暴露给访客。
3. 一次启用十几个插件「看运气」—— 无法定位，下次更新还会再炸。
4. 只修前台不测后台—— 不少错误只在wp-admin触发。
5. 修好后忘记关调试——debug.log会持续变大，也增加信息泄露面。

结语

更新后白屏，本质是：某次代码变更触发了 PHP 致命错误。
按「看日志 → 隔离插件 → 换主题 → 查环境 → 回滚防再犯」五层推进，你能在多数情况下30 分钟内让站点重新上线，并且知道下次该盯哪一个插件。

若五层做完仍无法恢复，把debug.log末尾 20～50 行、PHP 版本、最近更新的插件/主题列表发给主机商或开发者，比一句「网站打不开了」高效得多。