WordPress 白屏排查：前台白屏、后台白屏与主题白屏
白屏和 500 不是一回事。500 至少还你一个状态码，白屏是浏览器打开一片空白，右键查看源码只有几行空的 head，连主题输出的 header 都没有。这类故障多半是 PHP 执行到一半发生致命错误，而 display_errors 被关掉了，错误写进日志，页面上什么都不剩。判断清楚断点在哪一层，五分钟能定位；判断不清，换三套主题也修不好。
顺序不能乱：先确定是前台白屏、后台白屏，还是只有换回自己主题才白；再让 WordPress 把错误说出来；最后才是停插件、换主题这类动作。下面按这个顺序写。
先分清三种白屏
同样是白屏，断点位置差别很大。用下面这张表对号入座，比盲目重装快得多。
| 类型 | 现象 | 常见原因 | 处理 |
|---|---|---|---|
| 前台白屏 | 首页和文章页都白，/wp-admin/ 还能打开 | 主题 functions.php 报错、模板文件缺失、插件的前台钩子出致命错误 | 切默认主题验证，再二分插件 |
| 后台白屏 | 前台正常，登录后台一片白，或登录后跳空白页 | 插件后台页面致命错误、内存耗尽、更新中断、admin 核心文件损坏 | 重命名 plugins 目录，用 SQL 清 active_plugins |
| 主题白屏 | 换 Twenty Twenty-Four 正常，换回自己主题就白 | functions.php 语法错误、子主题缺父主题、模板调用不存在的函数 | 看 debug.log 里的 Parse error 行号 |
| 局部白屏 | 只有某个页面或某个短代码位置空白 | 该页面所用插件报错、文章内容里有失效短代码 | 停用对应插件，或切到经典编辑器看短代码原文 |
如果连 /wp-admin/ 都进不去，说明前台后台同时故障，跳过主题判断，直接按「全局故障」停插件。反过来，如果只有登录后的后台白、前台一切正常，大概率是内存或者某个后台页面插件的问题，不要一上来就换主题。
第二步：打开 WP_DEBUG，把错误逼出来
WordPress 默认把致命错误藏起来，页面上只显示「站点遇到技术问题」。要看到真实的报错文件和行号，改 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。刷新一次白屏页面，再打开这个文件看最后几十行，第一条 Fatal error 通常就是答案。日志文件不存在的话，是目录没有写权限，把 wp-content 改成 755、属主改成 www 再试。
几个高频原文对应的问题：
- Fatal error: Allowed memory size of 268435456 bytes exhausted —— 256M 上限被打满，问题在 wp-includes 或某个插件里。
- PHP Parse error: syntax error, unexpected ‘}’ in …/themes/xxx/functions.php on line 218 —— 主题文件语法错误，行号直接给到。
- Fatal error: Uncaught Error: Call to undefined function xxx() —— 调用了不存在的函数，多半是插件装了一半，或 PHP 扩展缺失。
- Fatal error: Cannot redeclare xxx() —— 同一个函数被定义两次，常见于子主题把父主题的 functions.php 整份复制。
线上站不要开 WP_DEBUG_DISPLAY。报错信息里带完整服务器路径，等于把目录结构公开。查完立刻把 WP_DEBUG 改回 false，debug.log 也要清空，日志里可能有数据库报错带出的敏感信息。
三类最常见的原因
内存耗尽
WordPress 给单次请求的内存从 40M 到 256M 不等，取决于主机。装了 WooCommerce、页面构建器、多语言插件的站，后台打开订单列表冲到 300M 很常见。表现是前台正常、后台特定页面白屏，或者只在导入、生成缩略图时白。临时抬高上限是在 wp-config.php 里加 WP_MEMORY_LIMIT 和 WP_MAX_MEMORY_LIMIT，但这两个值只能往「php.ini 给的硬上限」以内调，主机禁用了 ini_set 的话写了也没用。两层的具体关系在 WordPress 内存超限 里拆过。
主题 functions.php 语法错误
改主题文件最常见的翻车点：少一个分号、多一个括号、复制代码时把中文引号带进去了。PHP 7.0 以后这类错误是致命错误，整站白屏，不是只坏一个函数。定位就靠 debug.log 里的 Parse error 行号，打开文件看那一行和上一行。改之前先用 SFTP 把原文件下载一份，改错了直接覆盖回去，比在编辑器里反复撤销可靠得多。
插件致命错误与文件不完整
插件更新到一半网络断了，目录里可能只剩半个文件夹，主文件缺失或者目录名和版本号对不上，加载时直接 fatal。另一类是插件之间抢同一个函数名，表现为「装了 A 就白，卸了 A 就好」，这种用二分法排查最快，具体步骤见 插件冲突。还有一种隐蔽情况：自动更新把核心文件更新了一半，wp-includes/ 下少了文件，报错却指向一个看起来完全无关的函数。
判断文件完整不完整，最省事的办法是后台「更新 → 重新安装 WordPress」，它只覆盖核心文件，不动主题、插件和数据库。重装前仍然要备份，别把这一步当撤销键用。
应急处理：先重命名 plugins 目录
后台进不去、前台也白的时候，最快的一招是让 WordPress 看不见插件目录。用 SSH 或主机面板的文件管理器，把 wp-content/plugins 改名，再建一个空目录：
cd /www/wwwroot/example.com/wp-content
mv plugins plugins-off
mkdir plugins
chown www:www plugins
chmod 755 plugins这样 WordPress 加载不到任何插件，会按「插件全部停用」处理。站点恢复了，问题就锁定在插件里。接下来逐个恢复：
- 把 plugins-off 里的插件目录逐个 mv 回 plugins，一次只移一个。
- 每移回一个，刷新一次前台和后台。白屏复现就说明刚移回的那个有问题，把它留在 plugins-off 里。
- 插件多的时候不用全移，先移最近更新过的、最近新装的，命中率最高。
- 定位到具体插件后，看插件目录 readme.txt 里的 Requires PHP 和 Tested up to，多数冲突是版本不匹配。
注意：插件停用后，它注册的自定义文章类型、短代码、表单会一起失效，前台可能出现大片空白内容区。这是正常现象，别误判成新的故障。
后台白屏的三种绕过方式
能进数据库（phpMyAdmin 或命令行）的话，不碰文件也能恢复后台。三种方式按侵入性从低到高排：
- 改主题：把 wp_options 里的 template 和 stylesheet 改成 twentytwentyfour，后台就能进，进去后再切回来排查。
- 停插件：把 active_plugins 的值改成 a:0:{}，等价于全部停用。
- 提内存：在 wp-config.php 加 WP_MEMORY_LIMIT，多数「只有后台白」的情况到这一步就好了。
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name IN ('template','stylesheet');表前缀不是 wp_ 的先换成自己的。执行前把 wp_options 整表导出，出问题能立刻还原。改完登录后台，第一件事是去「插件」页确认列表还在，再逐个启用，不要一口气全开。
怎么防止再来一次
白屏几乎都发生在「改动」之后：改主题、装插件、升级版本、迁移服务器。把这几个动作规范住，复发率能降一大截。
- 改主题文件走子主题，父主题更新不会覆盖，出问题一键切回父主题。结构怎么搭见 主题定制。
- 插件和核心更新前先备份数据库和 wp-content，出问题十分钟能回滚，做法见 备份与恢复。
- 有条件就搭 staging 站，先在测试环境更新，确认前台后台都正常再推生产。
- 常开 debug.log 但关闭 display，每周扫一眼有没有新的 Fatal error，比等白屏了再查省事。
- 插件只留必要的。装之前看最后更新时间，两年没更新的插件在 PHP 8.2 上出致命错误的概率明显更高。
按上面的顺序走完还是白屏，大概率不是单一故障，而是主题和插件同时出问题，或者服务器层面缺 PHP 扩展。这种时候把 debug.log 最后 100 行、插件列表、PHP 版本一起发过来，比在后台反复试要快，联系方式在 联系页面。