WordPress 白屏或提示「出现了严重错误」：先开 WP_DEBUG 抓致命错误，再二分插件与主题

浏览器打开前台或后台，要么是纯白一页 ，要么跳出 WordPress 自带的「出现了一个严重错误 」（There has been a critical error on this website），偶发还有 HTTP 500 但正文几乎为空------这和今天已经写过的「登录后跳回登录页（Cookie / 站点 URL / HTTPS / CDN）」、「Elementor 编辑器空白转圈（REST / 内存 / Cloudflare）」以及「前台 502/503（PHP-FPM 池 / 上游超时）」不是一类故障：那些分别卡在会话、编辑器资源或网关能不能把请求交给 PHP ；这里卡在 PHP 应用层已经跑起来，却在某次致命错误（Fatal / Uncaught Error）处中断，或返回了空响应。

更稳的顺序是：先分清是 白屏 / 严重错误页 / HTTP 500 ，以及是前台、后台还是仅某条 URL → 安全打开 WP_DEBUG_LOG 抓第一条 fatal 的文件:行号 → 用恢复模式或 FTP 对插件/主题做二分 → 核对 mu-plugins 与 drop-in → 修复罪魁后做最小验证与回滚。别一上来就「全部停用插件」却不记日志，也别在生产把 WP_DEBUG_DISPLAY 开成对访客可见。

先分清：白屏 / 「出现了严重错误」 / HTTP 500 / 维护锁 / 文件损坏

「白屏或严重错误」常见落在六条线上，别和登录环、Elementor 空白、502/503 混着改：

白屏（空白 HTML） ：PHP 在输出缓冲清空前就 Fatal 了，或显示被关掉且没有友好错误页；有时是主题/functions.php 语法错误，浏览器 Network 仍可能是 200 或 500，但正文长度为 0。
「出现了一个严重错误」 ：WordPress 5.2+ 捕获到未处理的致命错误后的受控提示页 ；同页常带「了解详情」链到邮件/恢复模式（邮件是否发出取决于主机，不依赖邮件也不影响本篇定界）。关键是：应用层已确认 Fatal，不是网关连不上 FPM。
HTTP 500 ：Web 服务器把 PHP 失败映射成 500；可能与白屏或严重错误页并存。若同时有 Nginx connect() failed / upstream timed out，优先按今天 502/503 那条线排，而不是先二分插件。
Fatal 在插件 / 主题 / mu-plugin ：debug.log 第一条 PHP Fatal error / Uncaught Error 的路径落在 wp-content/plugins/、themes/ 或 mu-plugins/------定界已完成一半。
内存耗尽 ：Allowed memory size of ... bytes exhausted------表现也是白屏或严重错误，但根因是 memory_limit 或单请求吃内存的插件，二分时注意「关某个构建器/导入插件」会立刻好转。
.maintenance / 更新半截 / 文件损坏 ：自动更新中断会留下 .maintenance；主题/插件/核心文件缺页、被安全插件误删、或 opcode 缓存仍持有旧字节码，也会表现为白屏或 500。

另记两条易混项：REST / admin-ajax 单独 500 更像接口层（可与今天 Elementor 篇对照）；整站白屏而 curl 源站也空，才按本文「应用层 Fatal」推进。先记下：是否整站、是否仅后台、日志里第一条 fatal 路径、是否刚更新过。

第一步：安全打开 WP_DEBUG_LOG，先抓 fatal 文件:行号

生产环境原则：可以写日志，不要把错误打到前台 。在改 wp-config.php 前先备份该文件；维护窗操作。

在 wp-config.php 里（/* That's all, stop editing! */ 之前）加入或改为：

php 复制代码

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

WP_DEBUG 开调试总开关；
WP_DEBUG_DISPLAY 必须 false：避免把堆栈暴露给访客；
WP_DEBUG_LOG 写入 wp-content/debug.log（路径因主机/常量而异，以实际为准）。

复现一次白屏/严重错误（同一 URL、同一登录态），然后下载或 SSH 查看 wp-content/debug.log 末尾；同时打开主机/面板的 PHP / Nginx 错误日志，对齐时间戳（Asia/Shanghai）。
日志里优先找形如：

text 复制代码

[31-Oct-2026 01:00:12 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function foo() in /path/wp-content/plugins/bad-plugin/bad.php:42
Stack trace:
#0 /path/wp-includes/...

记下 第一条 Fatal / Uncaught 的 文件:行号 与插件/主题目录名；后面的 Notice/Warning 先别当主因。

预期定界：
- 路径在某个插件目录 → 优先停用该插件（或二分时把它放进「嫌疑组」）；
- 路径在当前主题 → 临时切默认主题（有备份/暂存环境更稳）；
- 路径在 mu-plugins 或 object-cache.php / advanced-cache.php → 后台「停用插件」点不到它们，必须 FTP/SFTP/文件管理器处理；
- Allowed memory size → 先核 Web 池 memory_limit，再查吃内存的插件，而不是无限加内存；
- 无新日志、但存在 .maintenance → 先删维护锁（确认无正在跑的正式更新）；
- 无应用日志、却有 upstream timed out / max_children → 回到 502/503 线，本文二分帮不上忙。
这一步结束时应能口头说清：「白屏还是严重错误页、第一条 fatal 在哪个文件哪一行、像插件还是主题还是 drop-in。」说不清就不要批量停用。

第二步：恢复模式 / FTP 二分插件与主题；核 mu-plugins 与 drop-in

已有明确文件路径时，先处理罪魁，不必全站盲关。路径不清或更新后集体炸时，再二分：

WordPress 恢复模式（邮件里的链接或主机提供的安全模式）：进入后可停用插件/切主题；适合后台也进不去的场景。没有邮件时，用 FTP/SFTP。
FTP 二分插件 （有备份；生产建议维护窗）：
- 将 wp-content/plugins 整目录临时改名为 plugins-off（或逐批移出一半）；
- 刷新故障 URL：若恢复 → 罪魁在移出的那一半，再对半缩小；
- 若仍挂 → 查主题、mu-plugins、drop-in，而不是继续盲关。
主题：在能进后台时切到默认主题（如 twentytwentyfive）对比；不能进后台则 FTP 将当前主题目录改名，WordPress 会回退默认主题。暂存或有备份再动生产主题文件。
mu-plugins 与 drop-in （常被漏掉）：
- wp-content/mu-plugins/*.php：必须改名/移走文件才能停；
- object-cache.php、advanced-cache.php、db.php：对象缓存/全页缓存 drop-in 损坏或后端 Redis 挂掉时，也可导致白屏或 500；临时改名验证后，再决定修复缓存配置还是换掉 drop-in。
一次只动一类假设 ：先记日志 → 再停一个嫌疑插件或半组 → 再切主题 → 最后动 mu/drop-in。每步刷新同一 URL，并回头看 debug.log 是否还出现同一条 Fatal。

插件与主题冲突、致命错误栈如何对照「激活顺序 / 共用函数 / 版本门槛」，可与站点侧的系统化记录对照同一条排查链：细节见插件冲突与致命错误排查，把「第一条 fatal 文件行号、二分结果、mu-plugin/drop-in」放在同一条链路上，而不是只反复重装核心。

第三步：定位罪魁后的修复：更新/替换、PHP 版本、opcode

更新或替换：若 fatal 指向过旧插件与新核心/新 PHP 不兼容，优先在备份后更新该插件；更新源不可用则换兼容版本或临时停用并找替代。主题同理------子主题里复制的过时函数也是常客。
PHP 版本兼容 ：日志若出现 syntax error、$xxx is deprecated 升级为 Error、或某扩展缺失，核对主机当前 PHP 小版本与插件声明要求；降级/升级 PHP 后重载 FPM，不要只改面板数字却忘了池在用的二进制。
Opcode 缓存：改完文件后白屏依旧时，重启 PHP-FPM 或清理 OPcache（面板「重置 PHP」类操作），避免旧字节码仍 Fatal。CDN/全页缓存再 Purge 一次，防止边缘仍吐旧错误页。
损坏文件：核对插件/主题目录是否缺文件（更新中断）；必要时删目录后重装同版本（先备份配置与授权信息到本地笔记，勿写进文章或公开处）。
不要同时：全停插件、切主题、升 PHP、Purge Everything、把 memory_limit 拍到 1G------一次一个假设，保留回滚点。临时 WP_DEBUG 用完后：生产建议保持 DISPLAY 关闭；日志过大则轮转或清除，避免磁盘打满。

第四步：验证与回滚

建议验收动作（同一维护窗口）：

故障 URL（前台关键页 + 后台 /wp-admin/）连续刷新为正常页面，不再白屏或「出现了严重错误」；Network 文档请求正文非空，状态码为约定正常码（多为 200）。
debug.log：复现操作后无新增同一条 Fatal / Uncaught；若仍有 Warning，另开任务，不与本次致命错误混治。
主机错误日志：无与本次时间戳对齐的 PHP Fatal；若曾动过 FPM/OPcache，确认池在跑。
插件/主题：罪魁已更新、替换或有意停用；mu-plugins / drop-in 若曾改名，已恢复正确配置或已替换损坏文件。
回滚：wp-config 调试常量、插件目录名、主题切换、drop-in 改名、PHP 小版本均可单条退回；备忘写清「改前值 / 改后值 / fatal 原文 / 时间戳（Asia/Shanghai）」。

排障窗口尽量短；确认稳定后把「白屏 vs 严重错误结论、第一条 fatal、二分结果」写进运维备忘，下次更新前先对备忘而不是先全站重装。

验收清单（技术）

已区分白屏 / 「出现了严重错误」 / HTTP 500，并排除明显的 502/503（upstream / FPM 池）与纯登录环
WP_DEBUG + WP_DEBUG_LOG 已开且 WP_DEBUG_DISPLAY 为 false；已记录第一条 Fatal 的文件:行号
已按路径处理插件/主题，或完成 FTP/恢复模式二分；mu-plugins 与 object-cache.php / advanced-cache.php 已核
罪魁已更新/替换/停用；PHP 版本与 OPcache/FPM 重载已按需处理；.maintenance 与损坏文件已排除
故障 URL 前台+后台稳定正常；debug.log 无新增同类 Fatal
可回滚 wp-config / 插件目录 / 主题 / drop-in / PHP 版本；临时调试已收束并写备忘