插件和主题多久更新一次、更新前做什么、出问题怎么回滚：一套按顺序走的流程

先给结论：安全类更新在 72 小时内安排，常规插件更新一个月一批，大版本更新单独排期、不要和其他更新混在一起。更新前必须做完的只有一件事——确认你能回到更新前的状态，具体是「有备份 + 验证过备份能恢复 + 记下了旧版本号」。出问题时的回滚顺序是：先停自动更新，再按「插件 → 主题 → 整站」逐层退，动过数据库结构的不要只回滚代码。

一、先把频率定下来

不要在周五下午、大促前一天、刚上线第二天更新。不是因为更新一定出问题，是出问题时你没人没时间处理。

二、更新前：六件事，做完再动手

1. 导出当前版本清单

mkdir -p ~/backup
wp plugin list --format=csv > ~/backup/plugins-$(date +%F).csv
wp theme list  --format=csv > ~/backup/themes-$(date +%F).csv
wp core version

这份清单是回滚时的「目标版本表」。没有它，出问题时你只能靠记忆猜旧版本号。

2. 完整备份，文件和数据库都要

wp db export ~/backup/db-$(date +%F-%H%M).sql
tar -czf ~/backup/files-$(date +%F-%H%M).tar.gz -C /var/www html

备份必须存到另一台机器或对象存储上。备份和站点放在同一台机器，等于没有备份。

3. 验证备份能恢复

至少确认 sql 文件能导入一个空库、tar 包能解开、里面文件数对得上。没验证过的备份不算备份，只算一个占空间的压缩文件。

4. 看 changelog，重点找三类词

• 数据库结构变更（加表、改字段）
• 破坏性变更（接口改名、配置项移除）
• 新的最低 PHP 要求

出现前两类，就按「大版本」对待，不要顺手更。

5. 有测试环境就在测试环境先更一遍

完整复制一份站点到子目录或临时域名，改本地 hosts 访问。没有测试环境的话，这一步至少要做到「先在备份恢复出来的那份上试」。

6. 选时间，留人

低流量时段，更新后至少留两小时有人能处理。夜里更新但没人看日志，等于把问题留到第二天早上。

三、更新顺序：一次一个，每次测

# 看有哪些可更新
wp plugin list --update=available
wp theme list  --update=available
wp core check-update

顺序建议：

1. 核心小版本（如果有）
2. 不碰前台、不碰数据的后台工具类插件
3. 影响前台的插件（表单、SEO、缓存、图片处理）
4. 电商 / 支付类插件（最后，风险最高）
5. 主题（放在最后，改版影响面最大）

wp plugin update <slug>
wp theme update <slug>
wp core update

每更一个，立刻跑下面的冒烟测试，通过了再更下一个。 全部更完再一起测的话，出问题你不知道是哪个引起的，只能一个一个退回排查。

四、冒烟测试清单（每次更新后都跑一遍）

• 首页能打开，页面上没有 PHP 报错输出
• 随便点开一个内页，图片、样式、字体正常
• 后台能登录，插件列表里没有红色报错横幅
• 站内搜索有结果
• 联系 / 询盘表单真实提交一次，用真实邮箱确认收到了信
• 有商城：加购物车 → 结账 → 下单，完整走一遍
• 有会员：登录 → 个人中心 → 退出
• 手机窄屏看一眼首页

邮件这一项最容易漏。 表单插件更新后 SMTP 配置被重置的情况不少见，而「提交成功」的提示是前端给的，跟邮件到底发没发出去没关系。只看提示不看收件箱，等于没测。

五、出问题怎么回滚

第一步：先定位在哪一层

第二步：先停掉自动更新

不然你回滚完，它过一会儿自己又更回去。

wp plugin auto-updates disable <slug>
wp plugin auto-updates status

第三步：按层回滚

单个插件回到指定版本：

wp plugin install <slug> --version=<旧版本号> --force
wp plugin activate <slug>

--force 是必须的。不加的话，检测到已经装了新版会直接跳过，你以为回滚了其实没有。旧版本号从第二步导出的 csv 清单里查。

主题同理：

wp theme install <slug> --version=<旧版本号> --force
wp theme activate <slug>

第四步：判断要不要连数据库一起回滚

这是回滚里最容易出事的点。如果新版本跑过数据库升级（加了表、改了字段、写了新的 option），只回滚代码会变成「旧代码 + 新表结构」，轻则报错，重则写坏数据。

判断方法：查 changelog 有没有提数据库变更，或者更新时后台有没有出现「需要升级数据库」的提示。

• 没有数据库变更 → 只回滚代码，够了。
• 有数据库变更 → 代码和数据库一起回到同一个时间点，也就是整站回滚。

整站回滚

# 1. 进维护模式，先别再让人访问
wp maintenance-mode activate

# 2. 恢复数据库
wp db import ~/backup/db-<时间点>.sql

# 3. 恢复文件
tar -xzf ~/backup/files-<时间点>.tar.gz -C /var/www

# 4. 清缓存：页面缓存、对象缓存、CDN 都清
# 5. 退出维护模式
wp maintenance-mode deactivate

第 4 步经常被跳过。 清完缓存再看效果，不然你会以为回滚没成功，然后再折腾一遍，把本来没坏的东西弄坏。

回滚完成后，把冒烟测试清单再跑一遍。只确认「首页能打开」是不够的，表单和结账往往还是坏的。

六、自动更新怎么设

自动更新的问题不是「会不会出错」，是「出错时你在不在」。所以按插件分别设：

核心小版本安全更新：可以开

wp config set WP_AUTO_UPDATE_CORE minor

插件：默认全关，只对个别单独开

wp plugin auto-updates disable <slug>
wp plugin auto-updates enable <slug>
wp plugin auto-updates status

判断标准很简单：这个插件出问题时，会不会影响收询盘、影响成交、动到已有数据。会，就不要开自动更新。

主题：不要开自动更新。 主题换版会同时改前台模板和样式，影响面比任何单个插件都大。

七、几个常踩的坑

• 备份做了但没验证，真出事发现 sql 文件是半截的。
• 文件和数据库不是同一时间点备份的，恢复后内容和模板对不上。
• 只回滚了插件没回滚数据库，或者反过来。
• 回滚完忘了清缓存，看起来像没回滚成功。
• 更新前没记录版本号，想回滚找不到旧版本在哪下。
• 一次全更，出问题不知道是哪个引起的。
• 大促前一周更新，出了问题没时间处理，只能硬扛着上线。

八、一页版

更新前：导版本清单 → 备份文件和数据库 → 验证备份能恢复 → 看 changelog 找数据库变更 → 挑低流量时段

更新中：核心 → 后台工具类插件 → 前台插件 → 电商插件 → 主题。一次一个，每次跑冒烟测试

出问题时：停自动更新 → 定位在哪一层 → 单插件回滚 → 判断有没有数据库变更 → 必要时整站回滚 → 清缓存 → 再跑一遍冒烟测试

更新后：观察 24 小时，看 PHP 错误日志和表单邮件有没有异常。