WordPress 白屏(WSOD):不改代码先开调试的 3 种方法

· wordpress · 阅读 9
摘要

先说结论:WordPress 白屏(WSOD)90% 是 PHP 致命错误被 display_errors 关掉后「静默死亡」。不要急着重装,先让错误显示出来——三种方法按顺序试,一般 5 分钟内能定位到具体文件和行号。 为什么是白屏而不是

先说结论:WordPress 白屏(WSOD)90% 是 PHP 致命错误被 display_errors 关掉后「静默死亡」。不要急着重装,先让错误显示出来——三种方法按顺序试,一般 5 分钟内能定位到具体文件和行号。

为什么是白屏而不是报错页

PHP 默认在生产环境关闭错误显示,一旦出现 Fatal error,脚本直接终止、输出为空,浏览器只看到一片白。所以白屏的本质是「有错误,但你看不见」。

方法一:改 wp-config.php 打开调试(最稳,推荐首选)

编辑站点根目录 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。刷新一次白屏页面,然后去读这个日志的末尾。

关键点:WP_DEBUG_LOG 为 true 时才写文件;很多人只开了 WP_DEBUG,结果页面上没显示、日志也没有,白折腾。

方法二:临时打开 PHP 错误显示(能直接看到行号)

如果连 WordPress 都没跑起来(比如 wp-config.php 本身有语法错),改配置文件是没用的。这时改 PHP 层:

  • 宝塔/面板用户:在 PHP 设置里把 display_errors 改为 On,error_reporting 设为 E_ALL,保存后刷新。
  • 命令行/自建环境:在站点入口临时加 ini_set('display_errors', 1); error_reporting(E_ALL);。

看到类似 Fatal error: Uncaught Error: Call to undefined function xxx() in /wp-content/plugins/yyy/zzz.php on line 42,问题就锁定了。

注意:定位完必须改回去,否则报错信息会暴露服务器路径,是常见的信息泄露点。

方法三:看服务器错误日志(最接近真相)

前两种都被插件改写屏蔽时,直接读服务器日志:

  • Nginx:/www/wwwlogs/站点名.error.log
  • Apache:error_log(位置见虚拟主机配置)
  • PHP-FPM:/www/server/php/81/var/log/php-fpm.log

日志里会带时间戳和完整堆栈,按白屏发生的时间点去对,比猜快得多。

定位之后:白屏的四大高频成因

成因典型报错快速验证
插件冲突Call to undefined function重命名 plugins 目录为 plugins_off,能进后台即插件问题
主题函数缺失Call to a member function on null切回默认主题(改数据库或重命名主题目录)
PHP 内存耗尽Allowed memory size exhaustedwp-config 里把 WP_MEMORY_LIMIT 提到 256M
PHP 版本不兼容语法错误 / Parse error面板里切回 7.4 或升到 8.1 试

插件排查的标准动作(别一个个点禁用)

  1. 通过面板或 FTP 把 wp-content/plugins 重命名为 plugins_off。
  2. 刷新,如果能进后台,说明是插件问题。
  3. 改回原名,再把插件子目录逐个重命名,二分法定位到具体哪个。
  4. 找到后先别删,看它是不是刚更新过——回滚版本往往比修代码快。

收尾:把调试关掉

问题解决后,把 WP_DEBUG 改回 false,删掉 debug.log。留着调试模式跑生产站,既拖慢速度,也会持续写日志占满磁盘。