WordPress 空白页面是一种症状，不是诊断结论。PHP 致命错误是一种可能性，但代理、服务器故障、不兼容更新或其他渲染问题也可能出现类似现象。修改文件或停用组件前，先记录发生了什么。
要点
- 记录受影响的 URL、时间、设备和近期改动。
- 尝试修复前先查看恢复邮件和私有日志。
- 可能影响生产环境的变更应在 staging 或获授权的恢复流程中进行。
检查故障范围
测试公开页面，以及可用时的 WordPress 仪表板。再检查其他页面、浏览器和网络。记录 HTTP 状态码，并确认是所有访客都受影响，还是只有某个路径出错。查看主机状态页面和近期部署记录。
查找 WordPress 恢复邮件，并检查故障时间前后的 PHP、Web 服务器和应用日志。调试输出应保持私密。如需启用 WordPress 调试日志，请遵照官方调试指南，诊断完成后将其关闭。
安全地排查近期改动
将故障时间与 WordPress 核心、插件、主题、PHP、配置和部署的变更对照。尽可能在 staging 环境复现问题。一次只测试一个疑似组件，并记录结果。没有备份、停机计划和恢复方式时，不要直接在生产网店重命名文件夹或切换主题。
如果仪表板和网站都无法访问，请让主机服务商检查服务器状态和访问日志。如果确认近期更新导致故障，应通过经过测试的流程恢复或回滚，然后先确认软件兼容性，再重新尝试。回滚可能无法撤销数据库变更，因此还要查看供应商说明。
验证恢复情况
测试出错页面及相关功能，包括表单、登录、结账和移动端显示。再次查看日志是否出现新错误，并记录根本原因、改动和恢复点。如果网站可能遭入侵或数据丢失，应按事件响应流程处理，不要只把白屏当作全部问题。
其他 WordPress 错误可参考五种常见错误排查指南。如果生产网站已停机且恢复路径不清楚，可联系 WordPress 紧急维修支持。
常见问题
一定是插件冲突吗？
不一定。插件可能是原因之一，但应通过日志和受控测试确认。
应该立即提高 PHP 内存吗？
没有证据时不应这样做。资源限制可能有关，但提高限制可能只是推迟问题，或超出主机套餐范围。
可以停用所有插件来修复吗？
这可能导致网站功能中断，也无法单独确认原因。应在 staging 安全测试，或按获批的事件流程操作。