WordPress 维护模式卡住怎么办？.maintenance 文件安全恢复
WordPress 维护模式卡住，最常见的现象是更新核心、插件或主题后，前台一直显示“正在执行例行维护，请稍候再试”。这通常不等于网站内容丢失，也不一定需要重装 WordPress；更常见的是更新流程中断后，站点根目录里的 .maintenance 文件没有按预期退出。
但我不建议看到提示就立刻删文件。更稳妥的顺序是：先确认更新进程已经停止，分清默认维护模式、维护插件和缓存页面，再建立回滚点，最后只处理真正触发维护模式的对象。这样既能尽快恢复访问，也不会把仍在写文件的更新过程再次打断。
WordPress 维护模式卡住时，先分清是哪一种页面
不同维护页面的处理方式完全不同。先看 HTTP 状态、页面文案和站点根目录，不要只凭外观判断：
| 现象 | 更可能是什么 | 第一步检查 |
|---|---|---|
| 标准维护提示，HTTP 503 | WordPress 核心更新维护模式 | 根目录 .maintenance 与 WP-CLI 状态 |
| 自定义倒计时、品牌页面，常返回 200 | 维护模式或 Coming Soon 插件 | 活动插件、页面规则和登录用户可见性 |
| 文件已不存在，部分地区仍看到旧页面 | 浏览器、页面缓存或 CDN 缓存 | 源站响应、缓存命中头和无缓存请求 |
| 空白页、500 或 Fatal error | 更新失败引发 PHP、插件或主题故障 | 错误日志与插件加载对照 |
如果实际返回的是 500 或错误日志出现 Fatal error，应改按 WordPress 500 错误排查流程处理，不要把所有 5xx 都当成维护模式。
WordPress 为什么会生成 .maintenance 文件
WordPress 执行核心、插件或主题更新时，会在安装根目录临时创建 .maintenance。当前 WordPress 7.1 核心的 wp_is_maintenance_mode() 会读取文件里的 $upgrading 时间戳；时间戳距当前不足 10 分钟时，WordPress 会进入维护模式。
默认维护响应是 HTTP 503，并带有 Retry-After: 600。如果 wp-content/maintenance.php 存在，WordPress 还可以加载自定义维护页面。核心更新正常结束后会退出维护模式；下载中断、PHP 超时、磁盘或权限异常、浏览器提前关闭，都可能让现场没有被正常收尾。
这里有个容易忽略的细节：核心代码会把超过 10 分钟的旧时间戳视为维护结束。因此，标准提示持续很久时，不要只盯着“文件存在”这一点；还要检查文件内容是否被持续刷新、是否存在自定义维护文件，以及缓存或维护插件是否仍在提供另一张页面。
第一步：先确认更新已经停止
刚点击更新后只过去几十秒，先等待一两分钟并观察后台、主机面板或部署日志。大型插件、共享主机和网络较慢的环境，写文件可能确实需要更久。下面这些情况更像“卡住”，而不是仍在正常更新：
- 维护提示持续超过预期时间，后台更新进度不再变化；
- 主机面板没有活动更新任务，PHP 或部署进程已经结束；
- 错误日志在同一时间出现超时、权限、磁盘空间或下载失败；
- 重新登录后台仍提示更新失败，且目标插件或核心版本没有完成切换。
如果不能确认更新是否仍在写文件，先联系主机商或查看进程与日志，不要直接处理 .maintenance。对于生产站，恢复访问之前也要确认最近备份可用；本站的 UpdraftPlus 远程备份设置可以作为备份思路参考。
第二步：用 WP-CLI 和文件检查交叉确认
有 SSH 和 WP-CLI 时，先执行只读检查：
cd /path/to/wordpress
wp maintenance-mode status
ls -la .maintenance
ls -la wp-content/maintenance.phpwp maintenance-mode status 用于判断 WP-CLI 识别到的维护状态；后两条命令分别检查根目录标记文件和自定义维护页面。看到“文件不存在”不是错误，它反而说明默认核心维护模式可能已经退出，需要继续查插件或缓存层。
没有 SSH 时，可以通过主机文件管理器、SFTP 或 FTP 打开包含 wp-admin、wp-content 和 wp-includes 的目录。注意开启“显示隐藏文件”，因为以点开头的 .maintenance 经常默认不可见。
第三步：安全退出 WordPress 维护模式
确认更新已经停止并准备好回滚点后，优先使用 WP-CLI：
wp maintenance-mode deactivate
wp maintenance-mode status如果 WP-CLI 无法加载，可以在站点根目录把文件改名，而不是直接永久删除。下面的示例文件名只是为了保留现场，确认恢复无误后再按你的备份策略处理：
cd /path/to/wordpress
mv .maintenance .maintenance.stale-20260825SFTP 或主机文件管理器同样可以把 .maintenance 改名。WordPress 官方文档给出的直接恢复方法是删除该文件；实际项目里我更倾向于先改名，因为它能保留时间戳和文件内容，方便确认更新为什么没有正常收尾。
一次本站只读实测：哪些结果才算互相印证
2026 年 8 月 25 日，我在本站 WordPress 7.1 环境做了只读检查，没有开启维护模式、更新插件或修改文件。结果如下：
| 检查项 | 本站结果 | 能说明什么 |
|---|---|---|
wp maintenance-mode status | Maintenance mode is not active | WP-CLI 未识别到活动维护模式 |
根目录 .maintenance | 不存在 | 没有默认维护标记文件 |
wp-content/maintenance.php | 不存在 | 没有核心自定义维护页面 drop-in |
| 前台 HTTP | 200 | 公开页面当前可正常访问 |
| 核心函数 | 存在 10 分钟阈值判断 | 与 WordPress 7.1 当前源码一致 |
这组结果不是为了证明本站曾经卡住，而是演示排查时怎样建立正常基线。单看首页 200，可能只是缓存；单看文件不存在，也不能排除维护插件。把多个只读信号放在一起，才不容易误删文件或误判故障层。
恢复访问后必须继续检查更新结果
移走 .maintenance 只是退出维护状态，不代表更新已经成功。至少继续检查：
- 首页、登录页、后台和关键业务页面是否返回预期状态；
- 核心、插件或主题版本是否已经完成切换，而不是停在半更新状态；
- 后台“更新”页面是否仍提示失败或需要数据库升级；
- PHP、Web 服务器和 WordPress 日志是否还有新的致命错误；
- 磁盘空间、目录所有者和写入权限是否满足下一次更新；
- 只清理必要页面和相关缓存，再从前台复测真实响应；
- 确认表单、登录、支付、订单和定时任务等关键功能没有受影响。
需要临时读取 WordPress 错误日志时，可以参考 WP_DEBUG 与生产环境日志安全排查。不要为了找原因把错误直接显示给访客，也不要在公开截图中暴露服务器路径、账号和密钥。
为什么维护模式会反复卡住
- PHP 超时或内存不足：更新流程在清理标记文件前中断；
- 磁盘空间不足：压缩包能下载，但解压或替换文件失败；
- 文件所有者或权限不一致：WordPress 无法覆盖旧文件或删除临时文件；
- 一次更新太多组件：执行时间拉长，也更难确认是哪一个失败；
- 网络或仓库连接不稳定：下载包不完整，更新停在中间阶段；
- 安全、缓存或部署工具介入：文件操作被阻止，或旧维护页被继续缓存。
如果每次更新都会重现，不要把“删除 .maintenance”当成永久修复。记录失败组件、时间和错误签名，先在测试环境复现，再处理权限、资源或兼容问题。一次只更新一个高风险组件，也比全部勾选后再猜原因更容易回滚。
总结
WordPress 维护模式卡住时，真正安全的恢复流程不是“找到文件就删”，而是先确认更新停止，分清核心维护模式、插件页面和缓存，再用 WP-CLI、文件与 HTTP 状态交叉验证。有备份后退出维护模式，并继续检查版本、日志、权限和关键业务，才能确定站点只是恢复显示，还是更新已经完整结束。
参考资料：WordPress.org《FAQ Troubleshooting》、WordPress.org《Updating WordPress》、Developer.WordPress.org《wp maintenance-mode》、Developer.WordPress.org《wp_is_maintenance_mode()》、Developer.WordPress.org《wp_maintenance()》
