WordPress 网站页面突然白屏报“致命错误”的解决方案

WordPress 站长最头疼的事情，莫过于打开自己的 WordPress 网站，迎接你的不是精心设计的首页，而是一片刺眼的白屏，中间只有一行冷冰冰的文字："此站点遇到了致命错误"。这就是传说中的"White Screen of Death"（WSOD），我们戏称为"白屏怪"。

常见诱因

WSOD的本质是PHP代码执行过程中遇到了无法处理的致命错误，与普通错误不同，它会导致整个页面渲染过程中断。常见诱因包括：

●插件/主题冲突（占60%以上案例）
●PHP版本不兼容（特别是升级到PHP 8+后）
●内存耗尽（WP_MEMORY_LIMIT设置不足）
●文件权限错误（尤其是自动更新失败时）
●数据库连接问题（wp-config.php配置错误）

WordPress 的致命错误大部分都是 PHP 代码错误引起，或者内存被撑爆引起的，最常见的是某个主题或插件写了有问题的代码，比如和别家用了同名函数，撞车了，造成冲突了。

解决方案

所以，搞清楚了成因，我们可以按照下面的顺序进行排查。

第一步：是所有站点都有问题，还是就这一个网站有问题？

如果你一台服务器上装了多个 WordPress 站点，先看看别的站点正不正常。要是大家集体躺平，那多半是服务器本身出问题了，直接联系服务商，问是不是线路或者机器挂了。

如果是只有这个站点不行，那可能是真的是这个站点的代码出问题了，那就针对该站点往下深挖。

第二步：是不是 PHP 内存不够？

很多时候出现白屏是因为 PHP 脚本的执行需要的内存太大，而服务器给的限额却太小，比如下面这种报错：

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2348617 bytes) in /www/xxx/wp-includes/plugin.php on line xxx

这种要么是程序写了死循环，要么是真的需要更多内存，先试着在 wp-config.php 里加大内存限制，把下面这行加进去，改成 256M 试试：

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

第三步：文件权限对不对？

还有一个可能引起白屏的原因可能是文件的权限和所有者不对，这个处理有点麻烦，如果不是很熟悉建议找个懂行的朋友帮你处理一下，别自己瞎改把站点搞更惨。

一般来说 WordPress 站点的文件的权限规则大致是这样：

●文件应该设置为 664 或者 644
●文件夹应该设置为 775 或者 755
●wp-config.php 文件应该设置为 660, 600, 或者 644

如果你可以使用 SSH 登录你的服务器，可以在 WordPress 根目录下的执行下面这行命令一次搞定：

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

第四步：是不是插件冲突？

如果前面的方法都没解决问题，接下来就怀疑插件，一个站挂了，十有八九是某个插件作的妖。

1、能进后台的话，最省事：到插件页，全选，批量操作里选「停用」：

停用后网站好了，就一个一个重新激活，每激活一个刷新一下出问题的页面，问题一复现，凶手就找到了。

2、进不了后台也别慌，用 FTP 进 wp-content 目录，把 plugins 文件夹改名成 plugins-old。

改完看站能不能开，能开就说明是插件的问题。然后改回 plugins，再挨个给单个插件改名，逐步定位。

第五步：是不是主题不兼容？

插件没问题，那就八成是主题。

1、我们可以通过切换回 WordPress 默认的主题来定位问题，如果还能进入后台，那么进入「外观」-「主题」，选择一个默认的 WordPress 主题。然后在出问题的界面刷新一下，如果问题重现，那就是主题的问题。

2、如果无法进入后台，处理方法和上一节处理插件一样的，使用 FTP 工具进入 wp-content 目录，重命名一下 themes 文件夹。这样 WordPress 会自动使用最新的默认主题。最后测试，如果问题重现就是插件的问题了，如果确定是，可以考虑换个主题。

第六步：清一下缓存

浏览器的缓存和插件的缓存也可能引起致命的错误，建议先清理掉。

如果你安装了缓存插件，比如 WP Rocket 或者 WP Super Cache，最快删除缓存的办法是通过插件的设置页面。比如 WP Super Cache，在「设置」-「WP Super Cache」-「删除缓存」即可清理掉缓存。

如果无法进入 FTP，那么缓存的文件在 wp-content/caches 目录下，可以进入进行删除操作。

第七步：放大招，开 Debug 模式

前面都不行，就上终极手段：直接看错误日志。其实我们平时排查都是跳过前面直奔这步的，因为对程序员来说，知道错在哪、错得具体、拿到 log，问题就解决一大半。

WordPress 提供了 WP_DEBUG、WP_DEBUG_DISPLAY 和 WP_DEBUG_LOG 这三个常量让你应对各种情况，下面讲经常使用到的方法：

场景1：是前台和后台都空白，并且没有显示任何错误。

打开 wp-config.php 文件，将原来的 WP_Debug 设置改成如下设置：

define('WP_DEBUG',true);define('WP_DEBUG_DISPLAY',true);

这样就可以直接看到错误的信息：

Cannot redeclare get_posts() (previously declared in 
/var/www/html/wordpress/wp-includes/post.php:1874) in 
/var/www/html/wordpress/wp-content/plugins/test-plugin/test-plugin.php on line 38

比如上面的错误信息就是在 test-plugin 插件定义了 get_post 函数，这个函数 WP 内置了，函数名冲突了。

场景2：错误是发生在某些后台进程。

比如 cron 定时作业或者微信自定义回复的时候，屏幕上没法显示错误 log，我们可以把 log 保存到 debug 文件。

打开 wp-config.php 文件，将原来的 WP_Debug 设置改成如下设置：

define('WP_DEBUG',true);define('WP_DEBUG_DISPLAY',false);define('WP_DEBUG_LOG',true);

然后就可以在 wp-content/debug.log 文件中看到相应的错误信息了。

最后一定要记得，测试完了一定要改回去，就是：

define('WP_DEBUG',false);

不然，你的用户也会看到你的系统错误了，或者 wp-content/debug.log 很大，把你服务器的空间都用完。

AI 时代：把错误日志丢给 AI

讲到 debug.log，就得说说现在不一样的地方了，以前拿到这一坨英文报错，得自己硬啃，或者贴到论坛等人回，现在，你直接把 debug.log 的内容复制下来，丢给 AI 就行。

跟它说一句：「这是 WordPress 的 debug.log，帮我定位是哪个插件或主题冲突，并给出修复建议。」它基本能秒读，告诉你哪一行是冲突、冲突的函数叫什么、该怎么改。

甚至你可以把「排查前六步的所有现象」一起喂给它，让它帮你列排查顺序、判断下一步该查内存还是查插件。AI 不会累，也不会嫌你啰嗦。

这里插一句，为什么前面要反复强调「把错误写得清楚、说原因」这么重要？因为现在读你报错的不只是人，还有 AI。

说白了，错误日志越是人话、越讲清楚为什么，AI 才能越准地帮你修。你写插件的时候把这两条做进去，等于同时帮了未来的用户和未来的 AI。

附加技巧：增强 PHP 文本处理能力

如果还没有解决你的致命错误，并且错误是发生在文章编辑页，并且很小的概率是因为文章太长造成的。

如果是这种情况，我们可以尝试一下增加回溯和递归限制来增强 PHP 文本处理能力，在 wp-config.php 文件添加下面的代码：

/* 针对特长文章的技巧  */ini_set('pcre.recursion_limit',20000000);ini_set('pcre.backtrack_limit',10000000);

总结

WordPress 致命错误不可怕，按上面这套顺序一步步来，总能揪出元凶，建议收藏本文，省得哪天白屏了抓瞎。

转载于：https://mp.weixin.qq.com/s/53kathkmYvAJ72gnf7Z2Dw