WordPress 故障：数据库连接、损坏与致命错误

1. 先记录报错和最近一次变更#

白屏、严重错误、数据库连接失败和 404 是不同问题。记录发生时间、访问地址、HTTP 状态码，以及最近是否更新插件、切换 PHP、迁移目录或修改数据库密码。先备份现状，不要同时停用所有功能又重装系统，让线索消失。

2. 数据库连接失败按顺序检查#

确认数据库服务运行，服务器没有磁盘满或 OOM。再核对数据库名、用户名、密码和主机地址；密码包含特殊字符时，检查配置文件的引号与转义。只在本机查看，不把完整配置截图公开。

systemctl status mysql
systemctl status mariadb
df -h

通常只会安装其中一种数据库服务，另一条不存在不代表故障。用应用账户做一次命令行连接，能区分服务不可达与权限错误。容器环境中数据库主机通常是服务名，而不是 127.0.0.1。

3. 严重错误先定位文件，再处理插件#

优先查看 PHP-FPM、Web 服务日志或 WordPress 恢复模式邮件。必要时可短期开启调试日志，但关闭前台错误显示，避免访问者看到系统路径和敏感信息。

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

添加前检查是否已有同名常量，不能重复定义。默认日志可能位于可公开访问的内容目录，要通过服务器规则限制读取或使用受控日志路径。排查结束后关闭临时调试并处理日志。

错误指向刚更新的插件时，先在后台停用该插件；后台也进不去，可通过 SFTP 暂时重命名这个插件目录，保留文件用于回退，不要删除整个 plugins 目录。

4. 表损坏要看数据库引擎#

先做可行的备份，再确认错误涉及哪张表、使用哪种引擎。历史文章中的 MyISAM REPAIR TABLE 不能直接解决 InnoDB 损坏。InnoDB 故障应按对应数据库版本的恢复文档处理，必要时从已验证备份恢复。

不要把 WP_ALLOW_REPAIR 长期留在配置中；使用 WordPress 修复入口也不等于完整数据库灾难恢复。出现磁盘或文件系统错误时，先停止继续写入并处理底层问题。

5. 修复后检查真实业务和后台任务#

测试首页、文章、搜索、后台登录、上传和一条会写入数据库的受控操作。检查错误日志不再新增同样报错，清理页面缓存后再用未登录浏览器访问。

若根因是 PHP 版本不兼容，按PHP 升级与回退处理；文章 404 看固定链接，容量与内存问题看磁盘和Swap。