wordpress更新后，网站一直停在“正在维护”，先别急着删文件。最先要确认的是：更新还在进行，还是已经中断。强行去掉提示只能让访问继续，并不能补齐更新失败的文件。
下面说的是自托管WordPress的核心维护模式。如果看到的是主机通知、维护插件做的自定义页面，或WordPress.com的托管提示，需要按对应服务的说明处理。
先分清是哪一种提示
核心维护模式常见的英文提示以“Briefly unavailable”开头，告诉访客稍后再试。它和“此站点遇到了致命错误”不是一回事。后一种情况可以看严重错误与恢复模式的排查方法，不要把两条流程混在一起。
如果刚在后台点过更新，先记下开始时间、更新对象和最后一条进度信息。不要连续点击更新，也不要同时开几个窗口重复操作。有主机后台或运维支持时，让有权限的人确认更新任务是否仍在运行。单凭浏览器不动了，不能断定服务器也停了。
.maintenance存在，不代表会无限维护
WordPress更新时会在安装根目录放置.maintenance文件。这里的根目录是包含wp-admin、wp-includes等目录的位置，不一定是主机面板显示的第一个目录。
核心函数wp_is_maintenance_mode()还会检查文件里的$upgrading时间戳。默认情况下，距离这个时间戳达到10分钟，就不再据此启用维护模式。因此，“有这个文件就永远进不去”并不准确。
这10分钟也不是更新一定完成的时限。提示自行消失，只说明维护判断可能已经过期。如果很久以后仍显示相同页面，还要查是否有更新任务重写时间戳、页面缓存，或主机和插件自己的维护层。
确认更新已停止，再处理残留文件
确认没有正在运行的更新任务后，先保留现有文件和数据库的可用备份。有备份不等于一定能恢复，尤其不要把文章修订当成整站备份，具体区别可看文章修订与备份的恢复范围。
随后使用主机文件管理器或SFTP进入这套WordPress的安装目录，开启“显示隐藏文件”。找到名称完整为.maintenance的文件，先下载留存，确认站点和路径无误后，再移除这一份残留文件。不要删除相似名称的目录，也不要顺手改动wp-config.php或wp-content。
WordPress官方故障FAQ给出了移除维护文件的处理办法，并提醒检查失败的更新。这里要把两件事分开：解除维护提示是一件事，完成更新是另一件事。
没有主机文件权限，就把提示原文、开始时间、更新对象和已做操作交给主机支持。不要为了找一个隐藏文件，临时安装来历不明的文件管理插件。
有WP-CLI环境，可以用命令检查
如果服务器已经具备WP-CLI，并且你确认当前目录对应目标站点，可以按官方维护模式命令说明查看状态：
wp maintenance-mode status确认更新停止且需要解除核心维护模式时，再执行：
wp maintenance-mode deactivate这些命令不负责修复更新内容，也不能代表主机或插件的维护页面已经关闭。不熟悉服务器目录和执行账号时，交给维护人员处理即可。
页面恢复后，还要确认更新结果
先用未登录窗口访问首页和一篇文章，再登录后台查看更新对象的实际版本与更新结果。如果仍有失败信息，记录原文，结合主机日志确认原因，再决定重试或回退，不要一口气更新所有插件来碰运气。
如果后台正常，只有访客仍看到旧提示，先比较不同页面和浏览器，再检查相关页面缓存或CDN缓存。清缓存应针对已确认的旧响应，不需要为了这一个症状关闭整站缓存配置。
把“访客能打开”“后台能用”“更新对象版本正确”分别确认，才算把这次维护问题查到了下一步。如果提示消失后出现致命错误，就转到对应错误排查，并把刚才处理过的文件和时间一并记录下来。
