wordpress突然提示“此站点遇到了致命错误”，连后台也打不开，先别重装。先确认有没有恢复邮件，再判断能否通过主机文件管理器排查插件。两种入口都没有时，把报错和最近改动交给主机支持，比盲目改数据库更容易保留现场。
下面针对自托管WordPress的常见处理入口。不同主机的文件路径和权限会有差异，不能把一套操作当成所有严重错误的通用修复。
先记下出错前改了什么
记录出错时间、打不开的具体网址，以及最后一次正常访问后做过的改动，比如更新插件、切换主题、调整PHP版本或粘贴代码。保留报错原文，截图时遮住账号、服务器路径等敏感信息。一次只处理一个线索，才能判断哪一步改变了结果。
如果页面写的是数据库连接错误、维护中或只有某篇文章404，先按对应错误排查。WordPress官方常见错误说明把这些情况分别处理，它们不一定都能靠停用插件解决。
有恢复邮件，先用邮件里的入口
恢复模式从WordPress 5.2开始提供，可在部分PHP致命错误发生后帮助管理员重新登录。检查站点管理员邮箱和垃圾邮件目录，先核对邮件里的站点域名，再使用恢复登录链接。
进入后查看错误通知指向哪个插件或主题。有明确线索时，先停用对应组件。如果问题紧接着修改代码出现，应由能处理该代码的人修正或回退，别为了消除提示又粘贴一段来路不明的代码。
恢复模式暂停问题组件的作用范围是当前恢复会话，能进后台不等于访客页面已经恢复。处理后退出恢复模式，再用未登录窗口检查前台和普通后台登录。
没有邮件，但能访问站点文件
邮件没到不能排除致命错误，服务器发信或邮件过滤都可能影响送达。若已有文件访问权限，可用主机文件管理器或文件传输工具进入正确的WordPress安装目录。改动前保存现有文件和数据库备份，记录目录原名，别直接删除插件。
已明确指向某个普通插件时，可临时修改它在wp-content/plugins/下的目录名。没有明确线索、需要排除全部普通插件时，官方FAQ给出的流程是：
- 把
wp-content/plugins临时改为plugins.hold。这会影响依赖插件的站点功能，先安排合适的处理窗口。 - 尝试进入后台的
/wp-admin/plugins.php插件页面，让WordPress识别插件缺失并完成停用。 - 再把目录名恢复为
plugins，回到后台逐个启用，每启用一个就检查原先出错的页面。问题再次出现时停止继续启用，记录对应插件。
这里的plugins.hold只是临时目录名示例，完整步骤见官方停用插件说明。恢复目录名和重新启用是两件事，不要跳过中间的插件页面确认。
这个办法针对普通插件目录，不能据此认定必须使用插件（mu-plugins）、多站网络启用项或主机注入组件也已排除。目录不一致、没有改名权限，或改名后仍无法进入后台，就先停在这里，让维护人员结合日志判断，不继续批量改主题和核心文件。
还进不去，把日志和改动交给维护人员
向主机支持提供出错时间、受影响网址、最近一次改动，以及已做过的目录改名和访问结果。请求查看对应时间的PHP错误日志，重点找最早出现的致命错误和所指组件。日志里出现一个插件路径是排查线索，仍需结合调用过程确认原因。
不要为了拿日志就在生产站长期公开显示报错。WordPress调试文档建议在测试环境或有适当备份时操作。由维护人员决定是否临时记录日志、如何限制访问，并在排查后关闭调试。
如果需要恢复备份，先确认备份覆盖哪些文件和数据库，以及备份之后新增的文章、评论或订单如何处理。文章修订和整站备份的恢复范围不同，恢复模式本身也不会替你还原整站。
恢复后，再检查真正受影响的功能
除了首页，还要检查原先报错的网址、后台正常登录，以及受影响的表单、搜索或下单流程。不要在真实订单上随意测试支付。若停用了缓存、安全或邮件插件，也要确认相应功能由谁接手恢复。
保留这次出错时间、问题组件和有效处理步骤。下次更新先在测试环境验证，站点再次出问题时，至少能从明确的改动开始查。
