WordPress 自动更新总是失败并提示“另一更新正在进行”?彻底解决思路与 6 种手动升级方案全记录
摘要:WordPress 自动更新在国内服务器上频繁卡住、报错甚至白屏,背后通常是网络连通性、文件权限和数据库更新锁三方面因素交织造成的。本文从最常见的“另一更新正在进行”提示切入,系统梳理清理更新锁的正确姿势,并逐一拆解离线包覆盖、镜像插件、本地包加载、宝塔面板操作、SSH 命令行和 WP-CLI 六种可落地的手动升级方案,最后补充升级后的权限修复与避险清单,帮助你彻底绕开自动更新反复失败的困局。
一次再普通不过的后台升级,为什么会让整个站点卡在“更新中”
很多站长都遇到过这种场面:后台仪表盘冒出 WordPress 新版本提示,点一下“立即更新”,进度条滚动几秒后突然静止,再刷新页面就是一片白屏。等你缓过神来重新进入更新页面,系统却冷冰冰地弹出一句:另一更新正在进行。
此时站点前台可能还能访问,但后台的任何升级操作都被死死卡住。更让人困惑的是,明知道没有第二个人在操作,系统却坚持认为有一场更新正在执行。遇到这种情况,多数人的第一反应是重启服务器、清缓存、甚至考虑重新安装 WordPress。但真正的问题,往往比你想象的要小得多。
要理解这个现象,得先弄清楚 WordPress 更新机制的三个薄弱环节。第一是网络连通性。WordPress 官方更新服务器部署在海外,国内服务器的出站连接质量不稳定,下载安装包时极易超时或中断。一旦下载流程被打断,更新进程就会留下半成品文件,为下一次失败埋下伏笔。第二是文件权限。WordPress 的运行用户(常见为 www 或 www-data)必须对网站目录拥有写入权限,如果之前用 root 账号操作过文件,或者权限配置过严,更新进程写不进去,系统便会静默失败或弹出 FTP 凭据窗口。第三是更新锁残留。WordPress 在更新时会向数据库的 wp_options 表写入一条名为 core_updater.lock 的记录,正常情况下更新结束后会自动清除;但如果更新被外力中断,这条记录就会一直赖在数据库里,后续所有更新请求都会被它挡在门外。
换句话说,那句“另一更新正在进行”并不是有人在跟你抢操作,而是上一次失败的更新在数据库里留下了一把没拔掉的钥匙。理清这个逻辑之后,解决路径就变得非常清晰:先解锁,再选一条自己能够驾驭的升级路线,最后把权限理顺,避免再次踩坑。
更新锁不是玄学:一条数据库记录如何卡住整个升级流程
当后台反复提示“另一更新正在进行”时,你并不需要重装 WordPress,也不必修改任何源代码。真正要做的,只是进数据库删掉一条记录而已。
这条记录藏在当前网站的 wp_options 表中,键名固定为 core_updater.lock。如果你的表前缀不是默认的 wp_,就按实际前缀去寻找对应的表。操作路径如下:
- 登录数据库管理工具。phpMyAdmin 是最常见的选择,宝塔面板用户也可以直接使用面板自带的数据库管理功能。
- 选中当前网站的数据库,找到
wp_options表并打开。 - 在表中搜索
core_updater.lock,通常只会匹配到一行记录。 - 删除这一行数据,保存即可。
回到 WordPress 后台重新触发更新,你会发现刚才的锁提示已经消失。但这里有一个需要冷静看待的事实:清锁只解决了“能不能开始更新”的问题,并没有解决“更新能不能顺利完成”的网络和权限问题。 如果你清完锁后直接再次点击自动更新,结果大概率还是失败,然后新一轮的锁又会被写进数据库。这就是为什么很多站长会陷入“清锁—更新—失败—再清锁”的死循环。
正确的做法是:把清锁当作一次“解除封印”的动作,在封印解除之后,不要再盲目地走自动更新这条老路,而是从下面几种手动方案中选择一种,从根本上绕开网络下载和权限写入的障碍。

动手覆盖任何文件之前,先把备份这件事做成肌肉记忆
无论你最终选择哪一种升级方式,在覆盖服务器上的任何文件之前,有三样东西必须完整备份。这不是可选项,而是出错之后唯一的退路。
| 备份对象 | 获取方式 | 注意事项 |
|---|---|---|
| 数据库 | phpMyAdmin 或宝塔面板导出 SQL 文件 | 结构和数据全部勾选,保存到本地硬盘 |
wp-content 目录 |
FTP 或面板文件管理器整体下载 | 主题、插件、上传文件都包含在内,不能遗漏 |
wp-config.php |
单独另存一份 | 包含数据库连接信息,覆盖文件时最容易误删 |
特别提醒:备份文件不要只放在服务器上。服务器硬盘一旦出问题,本地没有副本就前功尽弃。至少保留一份在个人电脑、移动硬盘或网盘中。
备份完成之后,还有两个升级前的小动作值得顺手做掉:一是停用不常用的插件,降低升级后发生兼容性冲突的概率;二是确认 PHP 版本满足新版 WordPress 的最低要求,官方建议 PHP 7.4 以上,否则升级后站点可能直接报错。

离线安装包覆盖法:最可靠、最不依赖环境的一条路
如果说六种手动升级方案里只能记住一种,那一定是这一种。离线覆盖法的思路极其朴素:从官网下载最新版安装包,用自己的手去替换服务器上的核心文件,完全绕开自动下载环节。 它不依赖服务器的出站网络质量,也不需要额外的命令行知识,适用面最广。
操作步骤拆解
第一步:下载并解压最新的 WordPress 中文安装包。 可以到 WordPress 中文官网获取,下载完成后解压,你会得到一个 wordpress 文件夹。
第二步:删除解压包里的 wp-content 文件夹。 这是整个操作中最关键的一步,没有之一。wp-content 是用户数据的聚集地——主题、插件、上传的图片和附件全部存放在这里。如果不清除它就直接覆盖上传,服务器上你正在使用的主题和插件会被安装包自带的默认文件一并洗掉,轻则样式错乱,重则内容丢失。
第三步:删除服务器上的 wp-admin 和 wp-includes 两个文件夹。 用 FTP 软件连接服务器,进入网站根目录,选中这两个目录直接删除。先删除后上传,可以确保旧版本的核心文件不会残留在里面干扰新版本运行。
第四步:上传本地剩余的所有文件到网站根目录,覆盖同名文件。 根目录级别的 index.php、wp-login.php、wp-settings.php 等通用文件会被新版本替换,这是正常的更新行为,不必惊慌。
第五步:登录后台确认是否需要进行数据库升级。 打开 你的域名/wp-admin/,如果系统提示需要更新数据库,点击确认即可;如果没有提示,说明版本跨度不大,数据库结构没有变化,升级已经完成。
这套流程最大的优势在于可控性。每一个步骤都看得见、摸得着,不依赖任何第三方服务,也不会因为网络抖动而半途而废。对于虚拟主机用户、没有 SSH 权限的站长以及第一次手动升级的新手来说,这是首选的稳妥路线。

WP China Yes 插件:用镜像加速把网络瓶颈“绕过去”
如果你不想手动操作文件,也不想碰任何代码,同时希望保留后台一键更新的便利性,那么国内开发者维护的镜像加速插件 WP China Yes 值得一试。
它的原理非常直白:WordPress 自动更新失败,很大程度上是因为从官方服务器下载安装包太慢、太不稳定。这个插件会在更新时把下载源替换为国内镜像,相当于给 WordPress 的更新请求换了一条“近路”。原本需要漂洋过海的下载请求,现在走的是国内节点,速度和成功率自然大幅提升。
操作流程很简单:
- 下载插件安装包。
- 登录 WordPress 后台,进入“插件 → 安装插件 → 上传插件”,上传 zip 包并启用。
- 回到“仪表盘 → 更新”,点击更新按钮。
- 更新完成后,可以保留插件继续用于插件和主题的加速更新,也可以临时停用或删除。
适用人群:预算有限、不想折腾文件操作的站长,尤其是对 FTP 和命令行感到陌生的新手。它的缺点在于插件本身可能不定期更新,如果镜像源失效,就需要切换到其他方案。另外,如果你需要降级到旧版 WordPress 核心,有专门的 WP Downgrade 工具可以处理,不在此展开。

本地加载更新包:一段过滤器代码让 WordPress 从“自己家”拿安装包
这个方法稍微进阶一点,但思路非常巧妙:手动把 WordPress 更新包上传到网站根目录,然后通过一段过滤器代码告诉 WordPress:“别去官方服务器找了,更新包就在你自己家里。” 它结合了离线包的可控性和后台更新的便利性,适合那些不想手动覆盖文件、但又希望彻底摆脱网络依赖的站长。
具体操作
- 从官网下载 WordPress 安装包,改名为
wordpress.zip。 - 把这个 zip 包上传到网站根目录,也就是与
wp-config.php同级的位置。 - 将下面这段代码添加到
