更新插件或 WordPress 核心后，网站一直显示“正在执行例行维护，请一分钟后回来”，可能是更新已经中断，安装目录里却留下了 .maintenance 文件。确认没有更新任务仍在运行后，可以备份并移走这个文件，让 WordPress 重新处理正常请求。
但维护页消失不代表更新完成。文件替换可能只进行了一半，数据库升级也可能尚未执行。恢复访问之后，还要检查更新结果和业务功能，不能把“删除一个文件”当作整套修复。
本文适用于自己拥有管理权限的 WordPress 单站点，使用 SFTP、主机文件管理器或 SSH 操作。托管平台、多站点网络和多节点部署应先确认服务商或发布系统的维护机制。文中路径和命令均为示例，没有在读者的生产环境执行。
先确认这是谁生成的维护页面
WordPress 核心更新器会在需要时启用维护模式。典型标记文件是 WordPress 安装目录中的 .maintenance，同一目录通常还能看到 wp-admin、wp-includes 和 wp-load.php。点号开头的文件在部分管理器中默认隐藏，需要开启显示隐藏文件。
核心判断不只看文件是否存在，还看文件里的 $upgrading 时间戳。按当前官方函数实现，时间戳距当前时间达到十分钟后，默认检查就不再判定为维护中。这个时间是代码判断条件，不能当作“十分钟后更新一定成功”的保证；过滤器、自定义维护页和缓存都可能改变最终表现。
如果几个小时后仍看到同一页面，需要检查是否有任务反复写入标记、服务器时钟是否异常，或者 CDN、页面缓存仍在返回旧内容。维护插件、主机面板、反向代理和负载均衡也可能独立返回维护页，未必与该文件有关。
观察响应状态、页面内容和相关日志，确认页面来自哪一层。WordPress 核心常规维护响应通常使用 503；自定义逻辑可能不同。只看到相似文案，不能直接认定应该删除文件。
更新还在进行时，不应解除维护
回到发起更新的后台、主机控制台或部署平台，查看任务记录和最后进度。如果是 SSH 发起的更新，联系操作人确认命令是否结束。浏览器关闭或页面超时，不能证明服务器上的 PHP 任务已经停止。
有服务器权限时，可结合进程、PHP-FPM 日志和文件修改时间判断，但单靠“有 PHP 进程”或“文件几分钟没变化”都不充分。记录更新对象、开始时间、错误信息，以及可用备份的时间点。
多节点环境还要确认标记文件是在共享目录还是各节点本地。只清理一个节点，可能出现有的请求正常、有的仍维护；若发布任务正在滚动替换节点，手工改文件还会与部署系统冲突。
确认任务已经失败或退出后，保存现场信息，检查更新前的文件与数据库备份是否可恢复。仍有活跃更新时，维持维护状态并处理卡住的任务，不要一边强行开放访问，一边让文件继续替换。
确认目录后，备份并移走标记文件
SFTP 和主机文件管理器用户可以先下载 .maintenance 留档，再将其移出网站公开目录。不要顺手删除 wp-content、wp-admin 或整个升级目录，也不要删除同名但属于其他站点的文件。
SSH 用户可以先执行只读检查：
# 替换为实际 WordPress 安装目录
cd /srv/www/example.com/public
pwd
ls -ld wp-admin wp-includes
ls -l .maintenance
确认路径正确、更新已结束后，再执行移走操作。以下备份目录必须位于公开网站目录之外，具备受控权限，并由合适的站点维护账户管理：
backup_dir="$HOME/wp-maintenance-backup"
mkdir -p "$backup_dir"
chmod 700 "$backup_dir"
mv -i -- .maintenance "$backup_dir/.maintenance.$(date +%Y%m%d-%H%M%S)"
这里不使用递归删除。mv -i 在目标文件已存在时会询问，避免覆盖已有记录。执行账户没有权限时，应核对文件所属用户和主机管理方式；不要递归设置 777，也不要为处理一个标记文件修改整站所有权。
若文件不存在，就转向维护插件、缓存和上游配置排查。wp-content/maintenance.php 可以定制核心维护响应，但它不是可随意删除的通用锁文件。真正的问题需要按当前环境定位。
使用 WP-CLI 时，命令要指向正确站点
已安装且可正常工作的 WP-CLI 提供维护模式命令。使用站点维护账户，并确认 --path 是实际安装目录：
wp --path=/srv/www/example.com/public maintenance-mode status
wp --path=/srv/www/example.com/public maintenance-mode deactivate
status 用于查看核心维护模式状态，解除操作仍需以确认更新结束为前提。命令不会修复已经损坏的插件、主题或数据库，也不能关闭外部网关的维护页。
不要为了让命令通过就直接使用 root 或忽略未知报错。遇到加载失败，应记录错误并按安装方式诊断。对于平台管理的 WordPress，应优先使用其支持的恢复入口，避免绕过发布流程。
解除后出现白屏或致命错误，继续处理更新结果
如果前台恢复，进入“仪表盘 → 更新”检查版本和待处理项，确认本次更新涉及的插件、主题或核心是否处于预期版本。出现数据库升级提示时，先确认数据库备份与版本兼容，再按官方流程完成。
如果出现白屏、缺失文件或 PHP 致命错误，应保持受控维护，读取服务器或应用日志，不要连续反复点击“全部更新”。可在测试环境复现，针对出错组件按官方恢复方式重新安装或回退；涉及支付、订单、会员等持续写入的业务时，恢复旧数据库会丢失备份之后的数据，必须单独制定数据处理方案。
对官方发行的 WordPress 核心，可以用校验命令辅助判断文件是否一致：
wp --path=/srv/www/example.com/public core verify-checksums
需要时按已安装版本和语言指定相应参数。校验结果只覆盖对应核心文件，不能证明插件、主题、上传内容和数据库都完整，也不能代替安全检查。自定义核心改动会产生差异，应先确认改动来源，不能未经判断直接覆盖。
有文件损坏时，使用官方包或可验证的已知备份修复相应组件。保留 wp-config.php、站点内容和必要的自定义配置，并遵循对应版本的升级或恢复文档。不要下载来源不明的“维护修复插件”来处理生产事故。
文件已移走，浏览器为什么仍显示维护页
用未登录窗口访问，并观察源站与缓存层是否一致。具备直连授权、源站支持对应 HTTPS 证书时，可以使用以下方式保留域名和 SNI 测试：
curl --resolve example.com:443:203.0.113.10 \
--connect-timeout 5 --max-time 15 \
-sS -D - -o /dev/null 'https://example.com/'
域名和文档保留 IP 都要替换为实际值。若源站使用专用回源证书或仅允许 CDN 访问，应使用平台支持的方法，不要忽略证书错误或永久开放源站来完成测试。
源站已经恢复、边缘仍旧维护时，再检查缓存状态与错误缓存策略，按受影响范围刷新页面。多节点需要逐个核对版本与标记文件。若 .maintenance 很快再次出现，说明仍有更新或部署逻辑在启用维护，应追查触发源，不能写定时任务反复删文件来掩盖故障。
恢复完成要检查哪些功能
分别验证首页、文章页、后台登录、媒体文件和表单。电商站还要在安全测试条件下检查商品、购物车与支付回调，避免用真实交易随意测试。响应状态码正常也要核对页面内容，确认没有缓存旧页面或跳到错误站点。
记录最终组件版本、日志错误是否停止，以及数据库是否完成所需升级。更新前的备份在确认恢复完成前应保留，恢复过程中生成的敏感日志也要限制访问。
下一次更新安排在低峰时段，先在测试环境验证兼容性，逐批更新组件，保留可恢复的文件和数据库备份。磁盘空间、inode、下载网络、PHP 内存和执行时间都可能使更新中断，应根据这次日志中的具体错误修复；没有证据时，不应无限提高资源限制。
解除核心维护只解决了访问入口的阻挡。文件、数据库和业务功能都通过验证后，这次恢复才算完成。
官方参考
资料核验日期：2026 年 10 月 21 日。