"此站点遇到了致命错误"：它到底是什么意思，以及怎么修

这句提示的意思是：PHP 在生成页面的过程中触发了致命错误，WordPress 在它变成一片空白之前把它接住了。错误是真实的、具体的、而且被记录下来了——WordPress 只是拒绝把它打印到浏览器里，因为在公开页面上输出堆栈跟踪，等于把文件路径和代码泄露给每一个访客。

所以修复它从来不需要靠猜。做法是：读出真正的错误，然后照它说的去做。

实际发生了什么

从 WordPress 5.2 开始，核心内置了一个致命错误处理器。当 PHP 在请求中途死掉时，处理器会接管，把崩溃输出替换成那句客气的通用提示，并且——如果它能判断出是哪个插件或主题引起的——尝试给站点管理员发一封带恢复模式链接的邮件。

这就是你现在看到的是这句提示、而不是过去那块白屏的原因。这是个进步，但同时也意味着诊断信息默认被藏了起来。这句提示有几种变体：

你看到的内容	出现位置	它告诉你什么
”此站点遇到了致命错误。“	前台，未登录状态	发生了致命错误，没有暴露更多细节
同一句话加上”了解更多关于 WordPress 故障排除的信息”	前台或 wp-admin	同样的错误，WordPress 顺手给了你官方手册页
”……请查看站点管理员邮箱中的说明。“	前台	处理器认为它已经发出了恢复模式邮件

第三种最有用。它意味着 WordPress 把这次崩溃归到了某个具体的插件或主题头上，并且试着给你留了一条进去的路。

第一步：查看恢复模式邮件

WordPress 把恢复链接发到站点管理员邮箱——也就是”设置 → 常规”里填的那个地址——它往往不是你登录用的那个。去那个邮箱里找，顺便翻一下垃圾邮件。

邮件里有一个很长的链接，结尾类似 ?action=enter_recovery_mode。打开它就能以恢复模式登录 wp-admin，闯祸的插件或主题会被暂停，并在顶部用红色提示标出来。到了这一步，正常停用它就行。

两个必须说清楚的前提。第一，这封邮件是由刚刚崩溃的那个 PHP 进程生成的，而主机可能根本没有可用的邮件发送通道——收不到很常见，收不到本身也说明不了任何问题。第二，恢复链接会过期（默认大约一天），所以邮箱里那封旧邮件可能已经失效；重新刷新一次网站触发崩溃，等新邮件就行。

如果你希望这封邮件发到你真正会看的邮箱，就在 wp-config.php 里显式指定：

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

第二步：读出真正的错误

这一步能把一个瘫痪的站点变成五分钟就能收工的小事。在 wp-config.php 里、“停止编辑”那一行的上方加入这几行：

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

把 WP_DEBUG_DISPLAY 设为 false 很关键——它让错误不出现在浏览器里，同时照样写进磁盘，这样你在排查的时候不会把服务器路径暴露给访客。

刷新一次出错的页面，然后打开 wp-content/debug.log。最后一条记录大致长这样：

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

那个文件路径就是答案。如果它指向 wp-content/plugins/，问题出在那个插件。如果指向 wp-content/themes/，那就是主题——很多时候是刚刚往 functions.php 里粘贴的某段代码。

如果 debug.log 一直不出现，可能是目录不可写，也可能是某个安全插件把日志挪到别处去了。这时候退回去看主机的 PHP 错误日志——大多数控制面板都有”错误日志”或”日志”一栏，同一条致命错误会带着时间戳出现在那里。

把这条记录粘进 WordPress 错误日志解读工具，它会把 PHP 的措辞翻译成实际含义，并告诉你该先看哪个文件。

排查完成后请删掉这些调试行。 在生产环境一直开着 WP_DEBUG 会撑爆磁盘；而且一旦 WP_DEBUG_DISPLAY 哪天被改回去，服务器路径就会被公开打印出来。

第三步：重新进入 wp-admin

如果 wp-admin 也打不开，恢复邮件又没来，那就在文件系统层面把所有插件停掉。用 SFTP（或主机的文件管理器）连上去，重命名一个文件夹：

mv wp-content/plugins wp-content/plugins-off

WordPress 找不到插件，就会把它们全部停用，后台访问几乎总能恢复。接下来：

1. 把文件夹改回 plugins。所有插件仍然是停用状态——WordPress 已经把它们记为未启用了。
2. 一次启用一个插件，每启用一个就去前台加载一次页面。
3. 让错误重新出现的那一个，就是元凶。

如果所有插件都关掉、站点依然打不开，那嫌疑就落在主题上。把 wp-content/themes/ 里当前主题的文件夹改名，如果系统里装了默认主题，WordPress 会自动回退到它。

值得了解的三个原因

插件或主题更新后 fatal。 这是目前为止最常见的。日志会直接点出文件名。把那一个插件回退到上一个版本，或者干脆保持停用，把日志那一行发给开发者。

PHP 版本不匹配。 主机会按计划升级 PHP，有时候提前通知得很少。为老版本 PHP 写的代码，在新版本上可能连解析都过不去。典型特征是：你这边什么都没动，所有东西却一起坏了。在主机面板里把 PHP 回退一个小版本是一种有效的诊断手段——但要把它当作争取时间，而不是修复。老版本 PHP 已经不再收到安全补丁了。

内存耗尽。 日志里会写 “Allowed memory size of X bytes exhausted”。在 wp-config.php 里提高上限是合理的：

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

但要如实看待它的作用：它只是把天花板抬高了，并没有解决”渲染一个页面为什么要吃掉 256MB”这个问题。如果这个上限需要一涨再涨，那真正的问题另有其人——通常是某次导入、某个页面构建器，或者一条写得很糟糕的查询。

可以放心忽略的建议

“把内存上限调大就行了。” 只有当日志确实写着内存耗尽时才相关。否则它什么都改变不了，只是掩盖了你从头到尾都没读过错误信息这件事。

“重装 WordPress 核心文件。” 核心文件极少是原因，替换它们浪费掉的时间，本可以用来读那一行日志。

“把致命错误处理器关掉。” 确实有一个常量可以禁用它，结果是原始错误直接打印在你的公开站点上，而不是被接住。那等于把文件路径暴露给访客。请改用 WP_DEBUG_LOG，同时关闭 WP_DEBUG_DISPLAY——信息一样全，暴露风险为零。

“清一下缓存。” 致命错误发生在 PHP 层面，早于缓存插件能返回任何内容的时刻。如果确实有一份错误页面被缓存了下来，清缓存是在你修好原因之后才有意义——绝不是用它来代替修复。

还是没解决？

如果日志指向的是核心文件而不是 wp-content 里的东西，更可能的解释是：某个更早加载的插件破坏了核心所依赖的状态，而不是核心文件损坏了。用重命名文件夹的办法把所有插件关掉，确认站点能干净地加载，然后一个一个放回来——错误重新出现前你启用的最后那一个，就是该去反馈的对象，记得附上日志里的那一行。