修复 WordPress 白屏死机（White Screen of Death）

WordPress 白屏死机本质上是一个关闭了错误显示的 PHP 致命错误：代码在生成任何 HTML 之前就崩溃了，而 WordPress 隐藏了错误信息，以免向访客泄露文件路径和服务器细节。

你更新了一个插件，重新加载站点，前端却是一片空白，很多时候 wp-admin 也一样。没有报错，没有堆栈跟踪，没有任何可点击的内容。此时很容易忍不住开始随机停用各种组件，但错误信息其实已经存在，只是没有展示给你看。下面的每一个步骤都可以通过 SFTP 或主机的文件管理器完成，对于只提供 phpMyAdmin 而没有文件访问权限的主机，我们也提供了数据库操作方案。

什么是 WordPress 白屏死机？

白屏意味着 PHP 在渲染页面之前遇到了致命错误，而 WordPress 会在生产环境站点上刻意抑制错误文本的输出，因为这些信息可能暴露路径、版本号和其他内部细节。站点的文件和数据库都完好无损，只是某个组件让这次请求崩溃了。

在动手之前，先检查管理员邮箱。从 5.2 版本开始，WordPress 会在发生致命错误时向管理员发送邮件，指明出问题的插件或主题，并附上一个进入恢复模式（Recovery Mode）的链接——在该模式下，出错的组件会被暂停，让你能够进入后台并将其停用。该链接中包含一个密钥，手动输入恢复模式的 URL 是无法获得访问权限的。如果这封邮件始终没有收到（可能被垃圾邮件过滤器拦截；另外该邮件只在错误发生于受保护端点时才会发送，例如 wp-login.php 或后台区域，而不包括前端页面或 cron 任务），请继续往下看。

开启日志记录，而非错误显示

通过 SFTP 或主机的文件管理器打开 wp-config.php，在 /* That's all, stop editing! */ 上方添加以下几行：

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

重新加载出错的页面，然后打开日志文件，通常位于 wp-content/debug.log。根据 WordPress 调试文档，除非 WP_DEBUG 为 true，否则 WP_DEBUG_LOG 不会生效；而 WP_DEBUG_DISPLAY 默认为 true，这正是上述代码片段要显式将其设为 false 的原因。切勿在线上站点将错误打印到页面上：每一位访客都会看到服务器路径和代码细节。站点修复后，请删除这四行代码。

读懂错误：路径即指认元凶

日志会给出文件名和行号，而路径中的目录会告诉你是哪个组件出了问题。一条真实的日志条目大致如下：

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

该路径位于 wp-content/plugins/acme-slider/ 之下，因此问题出在 Acme Slider 插件上，重命名这一个文件夹即可立即恢复站点。一般规律如下：

如果日志指向的是内存错误，请阅读下一节。只有在日志为空的情况下，才需要退而使用二分排查法。

如何修复 WordPress 内存耗尽错误？

以 Allowed memory size of X bytes exhausted 开头的错误意味着 PHP 在请求处理过程中触及了内存上限。在 wp-config.php 中提高 WordPress 的限制：

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

WordPress 中 WP_MEMORY_LIMIT 的默认值在单站点为 40M，多站点为 64M，并且它只会提高 PHP 的限制，绝不会降低。该常量仅在主机在服务器层面设定的上限范围内有效；如果设为 256M 毫无变化，那么限制来自主机套餐而非这个配置项，你需要联系主机商来提高上限。

没有 wp-admin 时如何停用问题插件？

如果日志指明了某个插件，只需重命名 wp-content/plugins/ 中该插件的文件夹即可。如果日志为空，则采用二分法：将 wp-content/plugins 重命名为 plugins.hold，访问 /wp-admin/plugins.php 让 WordPress 将缺失的插件标记为已停用，再把文件夹名改回来，然后逐个重新启用插件，每启用一个就重新加载站点，直到站点再次出错。这种方式的代价是需要手动逐一重新开启所有插件，但每个插件保存的设置都不会受到影响。

没有文件访问权限，但可以使用 phpMyAdmin？打开 wp_options 表（你的表前缀不一定是 wp_），找到 option_name 为 active_plugins 的那一行，先把当前的 option_value 复制或导出到安全的地方。然后将其值替换为序列化的空数组 a:0:{}，这会一次性停用所有插件。之后如果需要恢复原来的插件列表，把保存的值还原即可。

如何禁用出错的主题？

如果日志指向 wp-content/themes/，只需重命名当前启用主题的文件夹，例如把 mytheme 改为 mytheme.hold。如果安装了 WordPress 自带的默认主题，系统会自动回退到该主题；如果没有，请先通过文件管理器安装一个。最常见的罪魁祸首是 functions.php，而日志已经告诉了你确切的行号，通常是近期一次带语法错误的编辑。修好那一行，再把文件夹名改回来即可。

依然白屏？检查缓存、权限与 PHP 版本

在采信任何结果之前，先清除所有缓存：插件的页面缓存、任何服务器缓存以及浏览器缓存。被缓存的空白页会让已修复的站点看起来仍然有问题，而被缓存的正常页面则会掩盖线上仍在发生的错误。接着检查文件权限，在共享主机上通常目录为 755、文件为 644，并确认你的 PHP 版本：WordPress 推荐的基准版本是 8.3 或更高。运行在 7.4 上的站点仍然能加载，但该分支早在数年前就已停止接收安全修复。

有三种情况超出了本文的讨论范围：从备份恢复（使用主机的备份工具，注意会丢失快照之后的所有数据）、核心文件损坏（下载全新的 WordPress 并覆盖除 wp-content 和 wp-config.php 之外的所有文件）以及恶意软件感染（遵循主机商的被黑站点恢复流程）。

总结

WordPress 的空白页面是一条被抑制的错误信息，而非什么未解之谜，最快的修复方式永远是去读取这条信息，而不是靠猜测四处试探。现在就把那四行调试代码加入 wp-config.php，重新加载一次页面，让 wp-content/debug.log 中的路径准确告诉你该重命名哪个文件夹。

常见问题

白屏死机与“此站点遇到了严重错误”提示有什么区别？

从 WordPress 5.2 开始，内置的致命错误处理器会捕获大多数 PHP 致命错误，并显示严重错误提示信息，而不是空白页面。完全的白屏意味着 PHP 在该处理器运行之前就已终止，常见原因是内存耗尽，或是在加载流程非常早期发生的错误，例如 wp-config.php 内部的错误。两者都源于 PHP 致命错误，调试步骤完全相同。

为什么已经启用了 WP_DEBUG，wp-content/debug.log 却仍是空的？

常见原因有两个：一是错误在调试常量生效之前就已触发，例如 wp-config.php 本身存在语法错误；二是 web 服务器对 wp-content 目录没有写入权限，导致 WordPress 无法创建该文件。请确认这些常量位于 stop-editing 注释上方，然后向主机商索取服务器层面的 PHP 错误日志，无论 WordPress 如何设置，该日志都会记录致命错误。

为什么白屏只出现在某些页面上，而其他页面正常？

致命错误位于只在这些请求中执行的代码里。主题模板文件中的崩溃会导致前端空白，而 wp-admin 依然可用，因为后台不会渲染前端模板。反之，仅在后台执行的插件代码崩溃则会出现相反的情况。启用调试日志，加载一个出错的页面，日志中记录的错误文件路径就会指明出问题的组件。

站点修复后继续开启 WP_DEBUG 和 WP_DEBUG_LOG 安全吗？

不安全。日志默认写入 wp-content/debug.log，这是一个可预测且可通过网络访问的路径，许多主机并不会加以拦截，因此任何人请求该 URL 都能读取到文件路径、错误详情和插件内部信息，而且该文件会不断增长且不会轮转。站点恢复正常后请从 wp-config.php 中删除这些调试代码，或将 WP_DEBUG_LOG 设置为公开 web 根目录之外的自定义文件路径。