WordPress自动更新失败怎么办？六种手动升级方法+避坑指南一次讲透
摘要：国内服务器上点击WordPress“立即更新”，要么进度条卡死，要么直接白屏，再刷新还提示“另一更新正在进行”——这背后是网络、权限、数据库锁三重因素在作祟。本文从解锁开始，系统拆解六种手动升级方案，并附上备份清单、权限修复和升级前后避坑建议，帮你彻底告别更新焦虑。
一次点击更新，为什么换来白屏和锁死？
很多站长都经历过这样的场景：后台提示有新版本，满怀期待地点下“立即更新”，进度条走了一会儿就没了动静，刷新一看，要么报错，要么白屏。更令人抓狂的是，再次尝试时系统冷冰冰地提示“另一更新正在进行”，仿佛整个网站被一只无形的手按住了。
这其实不是运气不好，而是三个问题在同一时间爆发的结果。
首先是网络连通性。 WordPress官方更新服务器部署在海外，国内服务器的出站连接质量参差不齐。下载安装包时，一旦遇到超时或中断，更新流程就会留下半成品文件，为下一次失败埋下伏笔。
其次是文件权限。 PHP运行用户（通常是www或www-data）必须对网站目录拥有写入权限。如果之前用root账号操作过文件，或者权限配置过严，更新进程就写不进去，系统要么弹出FTP凭据窗口，要么干脆静默失败。
最后是更新锁残留。 WordPress更新时会在数据库wp_options表中写入一条core_updater.lock记录。如果上次更新被外力打断，这条记录不会自动消失，后续所有更新请求都会被它拦住。
搞清楚这三个根源，解决思路就清晰了：先解锁，再选一条适合自己技术水平的升级路径，最后修复权限防止复发。
第一步不是重装，而是先解开数据库里的“更新锁”
当你看到“另一更新正在进行”的提示时，别急着重装系统，也别去改源代码。真正的元凶就藏在数据库里——一条名为core_updater.lock的残留记录。
清理方法并不复杂：
- 登录数据库管理工具，phpMyAdmin和宝塔面板自带的数据库管理功能都可以。
- 选中当前网站对应的数据库，进入
wp_options表。如果你的表前缀不是wp_，按实际前缀查找。 - 搜索
core_updater.lock，找到后删除该行记录。 - 保存并退出，回到WordPress后台重新尝试更新。
需要注意的是，清锁只是解决了“能不能开始更新”的问题，并没有解决“更新能不能顺利完成”的网络与权限隐患。如果清锁后自动更新依然失败，那就需要下面的手动方案登场了。
动手前先备份：三样东西缺一不可
无论你选择哪种升级方式，在覆盖任何文件之前，都必须完成备份。这不是建议，而是底线。一旦出错，主题、插件、上传内容甚至整站数据都可能付诸东流。
| 备份对象 | 获取方式 | 注意事项 |
|---|---|---|
| 数据库 | phpMyAdmin或宝塔面板导出SQL文件 | 结构和数据全部勾选，保存到本地 |
wp-content目录 |
FTP或文件管理器整体下载 | 包含主题、插件、上传文件，不能遗漏 |
wp-config.php |
单独另存一份 | 包含数据库连接信息，覆盖时最容易误删 |
特别提醒：备份文件不要只放在服务器上。服务器硬盘一旦故障，本地没有副本就前功尽弃。至少保留一份在个人电脑或网盘里。
方法一：离线安装包覆盖法——最稳妥的通用方案
如果你只想掌握一种方法，选它就对了。核心思路很简单：从官网下载最新版安装包，手动替换服务器上的核心文件，绕开自动下载环节。
具体步骤如下：
第一步：下载并解压最新版WordPress安装包。 可以前往https://cn.wordpress.org/获取。下载完成后解压，会看到一个wordpress文件夹。
第二步：删除解压包里的wp-content文件夹。 这是整个操作中最关键的一步。wp-content是主题、插件、上传图片的聚集地，如果直接覆盖上传，你正在使用的主题和插件会被安装包自带的默认文件洗掉，导致内容丢失或样式错乱。
第三步：删除服务器上的wp-admin和wp-includes两个文件夹。 用FTP软件连接服务器，进入网站根目录，选中这两个文件夹删除。先删后传，可以确保旧版本的核心文件不会残留干扰新版本运行。
第四步：上传本地剩余的所有文件到网站根目录，覆盖同名文件。 根目录级别的index.php、wp-login.php等通用文件会被新版本替换，这是正常现象。
第五步：登录后台确认是否需要数据库升级。 打开你的域名/wp-admin/，如果系统提示需要更新数据库，点击确认即可；如果没有提示，说明版本跨度不大，数据库结构没有变化，升级已经完成。
这种方法适用于所有主机环境，不依赖服务器出站网络，也不要求命令行知识，是普通用户最稳妥的选择。
方法二：镜像加速插件——让更新请求走“近路”
如果你不想手动操作文件，也不想碰代码，可以试试国内开发者维护的镜像加速插件WP China Yes。它的源码托管在https://github.com/WP-China-Yes/wp-china-yes，可以免费下载使用。
它的原理并不复杂：WordPress自动更新失败，很大程度上是因为从官方服务器下载安装包太慢。这个插件会在更新时把下载源替换为国内镜像，相当于给WordPress的更新请求开辟了一条“近路”。顺带一提，国内服务器访问WordPress.org时还经常遇到429 Too Many Requests错误，这是官方对大陆IP的速率限制，镜像插件同样能有效规避。
操作流程：
- 下载插件安装包。
- 登录WordPress后台，进入“插件 → 安装插件 → 上传插件”，上传zip包并启用。
- 回到“仪表盘 → 更新”，点击更新按钮。
- 更新完成后，可以保留插件（它对插件和主题更新也有加速作用），也可以临时停用或删除。
适用人群：预算有限、不想折腾文件操作的站长。缺点是插件可能不定期更新，如果镜像源失效，需要切换到其他方案。
方法三：代码替换下载地址——把更新包“藏”在自家服务器
这个方法稍微进阶，但思路很巧妙：手动把WordPress更新包上传到网站根目录，再通过一段过滤器代码告诉WordPress：“别去官方服务器找了，更新包就在你自己家里。”
操作步骤：
- 从官网下载WordPress安装包，改名为
wordpress.zip。 - 将这个zip包上传到网站根目录（与
wp-config.php同级）。 - 将下面这段代码添加到主题的
functions.php文件中，或者使用Code Snippets插件添加（推荐后者，避免被主题更新覆盖）：
/**
* 临时更改WordPress程序包地址以便WP在线更新成功
*/
function lxtx_site_transient_update_core( $value ){
foreach ($value->updates as &$update) {
$update->download = home_url( 'wordpress.zip' );
$update->packages->full = home_url( 'wordpress.zip' );
}
return $value;
}
add_filter('site_transient_update_core', 'lxtx_site_transient_update_core');
- 回到后台点击更新。此时WordPress会从一个“看起来是官网、实际上是本地”的地址拉取更新包，成功率和速度都会大幅提升。
- 更新完成后，删除这段代码和根目录下的
wordpress.zip文件，避免长期残留。
如果你不想直接编辑主题文件，可以通过Code Snippets插件来安全添加代码。这个方法的优势在于不依赖任何第三方镜像，只要服务器自身能访问就不会失败。
方法四：宝塔面板文件管理器——浏览器里完成全部操作
对于使用宝塔面板的站长来说，文件管理器比FTP更直观，也不需要安装额外软件，整个流程在浏览器里就能搞定。
完整操作链路：
- 登录宝塔面板，从左侧导航进入文件。
- 进入网站根目录（通常是
/www/wwwroot/你的域名）。 - 点击远程下载，输入WordPress最新版的官方下载链接，确认后等待下载完成。
- 在下载完成的压缩包上点击解压，保持默认方法即可。
- 回到网站根目录，选中旧的
wp-admin和wp-includes文件夹，删除。 - 进入解压出来的
wordpress文件夹，删除其中的wp-content文件夹（理由同方法一）。 - 全选
wordpress文件夹里的剩余内容，点击剪切。 - 返回网站根目录，点击粘贴所有，覆盖旧文件。
- 打开后台查看版本号，确认更新是否到位。
这个方法本质上是“离线安装包覆盖法”的面板化版本，但因为宝塔自带远程下载和解压功能，省去了本地解压和FTP上传两个环节，效率更高。
方法五：SSH命令行覆盖——高效且可控
如果你有SSH登录权限，并且不害怕敲命令，命令行方式是最快速、最可控的选择。以下命令以LNMP环境为示例：
cd /home/wwwroot/website
# 把 website 替换为你的实际网站目录
wget https://wordpress.org/latest.zip
unzip latest.zip
rm -rf wp-admin
rm -rf wp-includes
cd wordpress
rm -rf wp-content
mv -f * ..
cd ..
chmod -R 755 *
chown -R www:www *
最后两条命令非常关键。 用root账号通过SSH操作时，新覆盖的文件所有者会变成root。而网站实际运行用的是www用户（或www-data，取决于环境）。如果不把所有者改回来，后续的插件安装、自动更新都会因为权限不足而失败，典型表现就是反复弹窗要求输入FTP登录凭据。
执行逻辑说明：先进入网站根目录，下载并解压最新版；删除旧核心目录；进入新解压的文件夹，剔除wp-content；把剩余文件移动到网站根目录；最后统一修正权限和所有者。整条链路一气呵成，熟练之后半分钟内即可完成。
方法六：WP-CLI工具——一条命令完成升级
除了手动覆盖文件，WordPress官方还维护着一个命令行管理工具WP-CLI。它能用一条命令完成核心、插件和主题的更新。安装WP-CLI可以参考官方文档https://wp-cli.org/。
如果你已经安装了WP-CLI，直接进入网站根目录执行：
wp core update
如果使用root身份登录SSH，需要加上--allow-root参数：
wp core update --allow-root
同理，更新所有插件和主题可以执行：
wp plugin update --all --allow-root
wp theme update --all --allow-root
WP-CLI的优势在于：它会自动处理好文件下载、解压和替换流程，而且同样可以配合--force参数强制执行。对于同时管理多个WordPress站点的站长来说，用WP-CLI配合脚本可以实现批量升级，大幅降低重复劳动。比如可以用cron定时任务在凌晨自动执行更新命令，实现真正的“零操作维运”。
升级完成后的权限收尾：别让FTP弹窗卷土重来
很多站长在手动升级后发现：更新是成功了，但下一次安装插件时又弹出FTP凭据窗口。这几乎可以确定是权限归属问题。
判断方法：回忆一下你升级用的是什么身份。如果用了SSH的root账号操作，那文件所有者大概率变成了root。而PHP进程不可能以root身份运行文件写入，于是WordPress只能求助FTP。
修复方式：
cd /www/wwwroot/你的网站目录
chmod -R 755 *
chown -R www:www *
如果是宝塔面板环境，网站运行用户通常是www；如果是Ubuntu/Debian的Apache环境，可能是www-data。如果不确定，可以用ps aux | grep php或ps aux | grep nginx查看当前PHP进程的运行用户，再进行修改。
有一个需要避免的坑：不要为了“省事”把权限设成777。这意味着所有用户都可以写入和执行文件，等于给潜在的恶意访问者打开了大门。正确的做法是目录755、文件644，所有者统一为网站运行用户。
升级前中后的时间线：把这些小事做对
把这些分散的建议汇总成一条完整的时间线，会更清楚：
升级前：
- 完整备份数据库和
wp-content目录。 - 停用不常用的插件，降低升级后冲突的概率。
- 确认当前PHP版本满足新版WordPress的要求（WordPress官方建议PHP 7.4以上），同时检查
memory_limit和max_execution_time是否足够。如果PHP内存限制过低，更新过程也可能因资源不足而中断。
升级中：
- 尽量选择网站访问量低的时段操作（如凌晨）。
- 不要中途刷新页面或关闭浏览器，尤其是自动更新进行时。
- 如果使用FTP上传，传输模式选择二进制，避免文本模式损坏文件。
升级后：
- 登录后台查看版本号是否发生变化。
- 逐批启用插件，每启用一批就刷新前台页面，观察是否出现白屏或报错。
- 检查固定链接、图片加载和表单提交等核心功能是否正常。
- 保留备份文件至少一周，确认网站持续稳定后再清理。
结语：可控比速度更重要
WordPress每年发布多个版本，其中安全更新尤其不能拖延。但更新本身不是目的，在不丢数据、不停机、不引发连锁故障的前提下平滑过渡到新版本，才是站长真正需要的能力。
国内服务器的特殊网络环境决定了，自动更新这条路并不总是一帆风顺。但好在方案并不缺乏：从最简单的清锁操作，到零代码的镜像插件，再到完全掌控的离线覆盖和命令行升级，每个技术水平的人都能找到适合自己的方法。
值得反复强调的只有一句话：先备份，再动手；先测试，再上线。 把这两条刻进操作习惯里，你会发现WordPress升级这件事，远没有想象中那么可怕。