WordPress 显示“此站点遇到了致命错误”怎么办？恢复模式、插件与 PHP 日志排查

先保住后台和数据：WordPress 显示“此站点遇到了致命错误”时，先查看管理员邮箱中的恢复模式邮件；有链接就从该入口登录，在“插件”或“主题”页面确认被暂停的组件。没有邮件时，进入宝塔“文件”或使用 SSH，读取 PHP/WordPress 错误日志，再只停用报错的插件或主题。不要先重装 WordPress、删除 wp-content 或清空数据库，这些动作可能让原本可回退的故障变成数据损失。

费用与风险：WordPress 恢复模式和读取日志本身不收费。备份存储、临时测试站、服务器扩容或第三方插件可能收费，应在控制台提交前核对。停用支付、缓存、安全、会员或商城插件会影响业务；切换主题可能改变布局；改 PHP 版本可能让其他组件一起失效。操作前备份数据库、wp-content、wp-config.php 和 Web/PHP 配置，并记录最近一次更新与故障时间。

为什么前台只显示一句致命错误

这句话表示 PHP 在处理请求时遇到了无法继续的错误。WordPress 5.2 以后包含恢复模式，常见插件或主题致命错误被识别后，会向站点管理员邮箱发送带专用登录链接的邮件，并在恢复会话中暂停有问题的扩展。它不会自动修好代码，也不保证邮件一定送达。

先回忆故障前几分钟发生了什么：更新了哪个插件或主题、切换了 PHP 版本、修改了代码，还是磁盘和内存已经告警。明确时间线能把几十个插件缩小到一两个候选。若没有任何变更，仍要检查磁盘满、文件缺失、权限变化和 PHP-FPM 故障，而不是认定 WordPress 核心突然损坏。

收到恢复模式邮件后怎么操作

1. 核对邮件收件人和站点域名，避免点击来源不明的仿冒链接。
2. 使用邮件中的恢复模式链接登录后台。该链接只为本次恢复会话提供入口，不应转发或公开。
3. 进入“插件 → 已安装插件”或“外观 → 主题”，查看 WordPress 标出的故障组件和错误详情。
4. 先停用该组件，不要直接删除。若刚升级，优先恢复到已备份且确认兼容的上一版本。
5. 退出恢复模式，用普通浏览器窗口重新验证前台和后台。

恢复模式只在当前管理员会话中暂停故障组件，普通访客不会因此自动看到完整正常站点。处理后必须用未登录窗口测试。邮件没有到达可能是管理员邮箱错误、垃圾邮件过滤、服务器邮件配置不完整，或致命错误发生在邮件相关插件加载之前；不能把“没有邮件”当成没有恢复模式。

没有恢复邮件，宝塔里从哪里取证

先进入宝塔“网站 → 目标站点 → 日志”，查看 PHP 错误日志和站点错误日志；不同 PHP 版本的日志入口可能位于“软件商店 → 已安装 → 对应 PHP → 日志”。记录第一条致命错误的时间、文件路径、行号和错误类型。后面重复的 Nginx 502 往往只是 PHP 失败的结果。

需要临时启用 WordPress 日志时，编辑站点根目录的 wp-config.php，在“停止编辑”提示之前加入或调整以下值：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

这会把错误写入 wp-content/debug.log，同时不在前台直接暴露路径和代码信息。先确认文件没有重复定义常量。日志可能包含绝对路径、插件名称、请求参数或用户信息，不要放到公开目录下载，也不要整份粘贴到论坛。定位完成后把 WP_DEBUG 与 WP_DEBUG_LOG 恢复为关闭，并按站点安全策略删除或归档日志。

后台完全打不开时怎样只停用一个插件

错误路径若明确指向 wp-content/plugins/example-plugin/，在文件管理器或 SSH 中把这个插件目录改名，例如：

mv wp-content/plugins/example-plugin wp-content/plugins/example-plugin.disabled

命令必须在真实站点根目录执行，并把目录名替换为日志中的插件。改名前确认当前路径和备份。WordPress 找不到原目录后会停用该插件，但插件文件和数据库表仍保留，便于回退。若站点恢复，先核对插件更新说明、PHP/WordPress 兼容范围和授权，再决定安装修复版或恢复旧版。

只有日志无法定位且停站影响较大时，才把整个 plugins 目录临时改名做二分排查。确认站点能打开后，应恢复目录名，再逐个启用；长期保留全停用状态会让缓存、安全、表单、商城和定时任务全部失效。

主题错误怎样处理才不会丢布局

如果错误来自当前主题，先确认站点已经安装一个可用的 WordPress 默认主题，再临时切换。直接删除当前主题目录不是默认处理，因为自定义代码、子主题和页面模板可能只存在于该目录。保留完整备份，并记录父主题与子主题关系。

使用子主题时，错误路径可能落在父主题，也可能是子主题的 functions.php。不要只看页面上显示的主题名称。恢复旧版本前核对数据库与页面构建器是否有同步升级，避免代码回退但数据结构已经改变。

根据日志内容走不同分支

日志关键词	更可能的原因	优先动作
Call to undefined function / Class not found	依赖未加载、文件缺失或版本不兼容	核对报错组件版本和完整性，恢复匹配版本
Allowed memory size exhausted	单次请求超过 PHP 内存或插件循环	先定位调用栈和异常请求，不把内存无限调大
Parse error / syntax error	手改代码或更新文件不完整	恢复改动前备份，从版本库或可信安装包还原文件
Uncaught TypeError	PHP、插件或主题 API 兼容问题	回到上一组已验证版本，再在测试站升级
No such file / 权限错误	发布缺文件、属主或权限变化	核对文件清单和运行用户，不用 777 兜底

若错误发生在切换 PHP 版本之后，默认先恢复到更新前已正常运行的 PHP 版本，再核对 WordPress、主题和插件对目标版本的支持。不要因为“新版更安全”就在故障现场同时升级 WordPress、PHP 和所有插件；安全升级应在备份和测试站通过后分步完成。

哪些修复动作不应该直接在生产站做

• 删除整个插件或主题目录，而没有可还原备份。
• 覆盖 wp-content 或 wp-config.php 来“重装核心”。
• 把 PHP 错误直接显示给访客，暴露路径、账号或请求信息。
• 把所有目录权限改成 777，掩盖真实属主和运行用户问题。
• 同时修改 PHP 版本、数据库版本、缓存和主题，导致无法判断哪个动作有效。

怎样验证修好，失败时怎样退回

1. 用未登录窗口打开首页、文章页和一个不存在页面，确认不再出现致命错误。
2. 登录后台，检查插件、主题、站点健康和固定链接页面。
3. 执行一次登录、表单、上传和搜索；商城还要检查购物车、结算与回调入口。
4. 观察 PHP、Nginx 和 debug.log，确认没有新的 fatal error。
5. 再验证 WP-Cron、备份、缓存清理和邮件，避免主页面恢复但后台任务仍失败。

新版本再次报错时，停用该版本并恢复已验证备份；如果改了 PHP 版本，恢复原版本和对应 PHP-FPM 配置。确认站点稳定后再关闭调试日志。出现 502 时可结合宝塔 PHP 502 排查；计划任务受影响时参考WordPress WP-Cron 排查；恢复后上传仍失败可查看宝塔上传 413 分层限制。

官方依据

• WordPress：恢复模式入口与处理方式
• WordPress Developer Resources：调试与日志配置
• WordPress Developer Resources：致命错误处理机制