WordPress严重错误怎么排查？

当后台只抛出“此站点出现严重错误”时，站点往往已经无法正常渲染，开发者必须在没有图形化后台的情况下直接定位根因。下面的步骤围绕 PHP 报错、插件冲突、主题失效以及核心文件完整性展开，力求在最短时间内恢复可用性。

开启调试模式

在 wp-config.php 最底部加入以下常量，即可让 WordPress 将致命错误输出到页面或日志：

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

保存后，wp-content/debug.log 将记录所有 PHP 警告与致命错误，打开该文件即可看到触发错误的文件路径与行号。

检查错误日志

服务器的错误日志往往比 WordPress 自带的 debug.log 更完整。通过 SSH 或主机面板进入 /var/log/apache2/（或 /var/log/nginx/），检索最近的 error.log，搜索关键词 “PHP Fatal error”。举例来说，若日志显示：

PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_current_user() in /wp-content/plugins/example-plugin/example.php:27

则说明是该插件尝试在加载顺序不当的阶段调用核心函数，属于插件冲突。

快速定位插件冲突

• 使用 FTP 或文件管理器，进入 wp-content，将 plugins 文件夹重命名为 plugins.deactivate。
• 刷新站点首页，若错误消失，则必然是插件导致。
• 恢复原名后，逐个在后台激活插件，每次激活后立即访问前端，直至错误再次出现。

此方法不依赖邮件恢复模式，适用于所有主机环境。

主题与核心文件排查

若插件排除后错误仍在，可尝试切换到官方默认主题。通过 FTP 删除 wp-content/themes 中的自定义主题文件夹，或直接将其重命名，WordPress 会自动回退到 twentytwentyone（若已安装）。

核心文件受损时，最稳妥的办法是重新上传官方压缩包中的 wp-admin 与 wp-includes 目录，覆盖现有文件。务必保留 wp-config.php 与 wp-content。

利用 WP‑CLI 进行恢复

在支持 SSH 的环境下，执行 wp plugin list --status=active 可以快速列出激活插件；随后使用 wp plugin deactivate --all 一键停用全部插件。主题切换同理，wp theme activate twentytwentyone 即可完成。

结合上述手段，基本可以在数分钟内锁定导致“严重错误”的根源，随后针对性修复或替换有问题的组件，站点即恢复正常