WordPress 致命错误，页面白屏，后台进不去，教你一步一步定位和使用 AI 解决！

Denis | 邓鸿华 WordPress 7634 2013年02月28日

WordPress 用户最怕的事，就是打开网站一片白，或者后台死活进不去。这就是 WordPress 的致命错误，英文叫 White Screen of Death，圈内简称 WSoD，中文我们叫它白屏错误。

此图像的alt属性为空；文件名为image-20.png

同样类似的，用 #WPJAM Basic# 插件的同学问得最多的一个问题也是：xxx主题就不能用了，xxx插件就报错了？

说白了，这些都是兼容问题惹的祸，造成了 WordPress 致命错误。一般我都是建议：先停用其他插件、换回默认主题，看问题还在不在，然后一个一个加回来排雷。

那么怎么排雷呢？下面我们就把「什么是致命错误、怎么一步步定位、怎么解决」彻底讲清楚。顺带，现在是 AI 时代了，我也会告诉你怎么用 AI 把排错这件事变轻松。

排查顺序是：先看是不是服务器的事，再查内存、权限，然后插件、主题、缓存，最后开 Debug 放大招。下面一步步来。

什么是 WordPress 致命错误

平时访问好好的，突然整站变白屏，或者不同浏览器给不同提示，比如 Chrome 底下甩你一个 HTTP 500：

如果火狐浏览器上面，那么就是白屏了，没有任何有用的信息：

如果 WordPress 开启了致命错误处理，还会显示一段错误提示：

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

所以 WPJAM Basic 引发的大多数问题，本质就是别的主题或插件，跟 WPJAM Basic 用了相同的函数或类库，冲突了。

搞清楚了成因，下面按顺序排查。

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

如果你一台服务器上装了多个 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，再挨个给单个插件改名，逐步定位。

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

插件没问题，那就八成是主题。很多 #WPJAM Basic# 的兼容问题大部分是主题引起的，不少主题使用了和 WPJAM Basic 同名的函数。

比如我博客上分享过一些自己写的工具函数，都尽量用 wpjam_ 开头，可有些主题原封不动抄过去用了，WPJAM Basic 里刚好也有，于是就冲突了。

1. 我们可以通过切换回 WordPress 默认的主题来定位问题，如果还能进入后台，那么进入「外观」-「主题」，选择一个默认的 WordPress 主题，比如最新的 2024：

然后在出问题的界面刷新一下，如果问题重现，那就是主题的问题。

2. 如果无法进入后台，处理方法和上一节处理插件一样的，使用 FTP 工具进入 wp-content 目录，重命名一下 themes 文件夹。

这样 WordPress 会自动使用最新的默认主题，比如现在就是 2024。最后测试，如果问题重现就是插件的问题了，如果确定是，可以考虑换个主题。

第六步：清一下缓存

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

如果你安装了缓存插件，比如 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 时代产品怎么做？WordPress 之父 Matt 给出了自己的 10 条防御性数据设计原则！」，里面两条原则几乎是给 AI 时代量身定做的：一条是「报错要像跟朋友解释那样，旁边放个复制按钮」，一条是「报错了说为什么，别说只说出了什么错」。

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

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

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

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

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

总结

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

用 WPJAM Basic 出了问题的同学也别慌，更别上来就一句「我出问题了」然后啥细节没有，谁也帮不了你。先按上面的方法自己走一遍，最后把相关的错误 log（重点看怎么生成 log 那节）发出来，我们就能帮你定位、帮你解决。

最后说两句：我现在写教程、排错都越来越喜欢让 AI 搭把手，读 log、给修复代码，效率翻倍。但 AI 再强，也得你先把错误日志搞对、搞清楚，这又绕回那句话，把危险动作设难、把安全动作设易，本质上就是给工具（人和 AI 都算）套上缰绳，让它在安全的范围内驰骋。

你们平时碰到的 WordPress 致命错误，都是什么奇葩原因？又是怎么解决的？评论区聊聊。

©我爱水煮鱼，本站推荐使用的主机：阿里云，国外主机建议使用BlueHost。

本站长期承接 WordPress 优化和建站业务，请联系微信：「chenduopapa」。

标签：