WordPress 插件和主题多久更新一次：更新窗口怎么排、回滚怎么留一手

周三上午客户来信问，昨天下午提交的报价表单你们收到了吗。你打开后台，发现前一晚自动更新了几个插件，其中一个是表单相关的。于是去找备份，发现最近的一份是三天前的，而且从来没有真的恢复过。

更新频率和回滚能力是同一件事的两面。只定节奏不留退路，等于每次更新都在赌；只留备份不定期更新，又会把一堆安全补丁越攒越多。下面这套流程可以照着改。

更新节奏按影响面分档

不是所有更新都值得半夜爬起来。判断顺序：这个漏洞能不能从前台匿名触发、是不是需要管理员权限、受影响的代码在你站上有没有被调用。三条都命中才属于要插队处理的那类；其余跟着常规窗口走。常规窗口一个月一次，固定星期几、固定时段，团队里所有人都知道。大版本更新先在影子站跑一到两周，看日志和前台功能，再排进常规窗口。

给常规更新一个承诺：从官方发布到你在站点上评估完，不超过一周。拖到几个月不更的站，真正的问题不是那一次的版本号，而是没人知道哪个插件卡在旧版本上。

窗口怎么选

选流量低谷，选你接下来几个小时能坐在电脑前的时段，避开投放期和大促。窗口长度从「开始备份」算到「验证通过」为止，里面要包含回滚的时间预算——如果你的窗口只够更新、不够回滚，那它不算窗口。

动手之前，把这几样东西留下来

先记录现状，出事时这就是你要回去的坐标：

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

然后备份，数据库和 wp-content 要落在同一个时间点。只备数据库或只备文件，回滚时会遇到「表是新的、代码是旧的」这种半截状态。

备份做完必须验证能恢复：在一个独立环境把库导进去、把目录铺开，核对表数量、siteurl 和 home、uploads 下的文件数、启用中的插件列表是否和备份时一致。看到「备份成功」不等于能恢复，只有真的恢复过一次才算。

窗口开始前先把自动更新关掉，避免你手动更新到一半后台又自己动了一次：

wp config set AUTOMATIC_UPDATER_DISABLED true --raw

窗口结束、验证通过后记得改回 false，否则安全更新会一直等你手动来。

更新的顺序

先在影子站把全部更新整体跑一遍，拿到一份「哪些会炸」的名单；生产环境上一次只动一个组件，每动一个跑一遍下面的冒烟清单。

顺序上的原则：核心的小版本安全更新可以单独先上；然后更被依赖的那个（电商、表单这类承载业务数据的插件通常是被依赖方），再更依赖它们的扩展；主题放最后，因为主题往往带着模板覆盖，改完整个前台都受影响。

别在生产上直接 wp plugin update --all，除非你已经在影子站整体验证过一轮。

每次更新后都要跑的冒烟清单

下面这段脚本里不写死站点地址，执行前在自己的 shell 里把 SITE_HOST 设成你的站点地址，再跑：

# SITE_HOST 由执行的人在 shell 里提供，例如 export SITE_HOST=...
for p in / /shop/ /cart/ /contact/; do
  printf '%-10s' "$p"
  curl -s -o /tmp/p.html -w '%{http_code} %{time_total}s\n' "${SITE_HOST}${p}"
  grep -qiE 'fatal error|There has been a critical error' /tmp/p.html \
    && echo '   !! 页面正文里有 PHP 错误'
done

再人工过一遍：

• 提交一次测试表单，确认邮件收到、后台有记录、webhook 那头也收到。
• 走一遍加购到下单（用测试支付），确认支付回调正常。
• 后台登录、保存一篇文章、上传一张图。
• 清页面缓存、对象缓存和 CDN，然后重跑上面两轮。很多「更新后样式全乱」其实是缓存里新旧文件混着。
• wp cron event list 看有没有任务卡在失败状态。
• 翻 wp-content/debug.log 和 PHP error log 的新增行。排期窗口里可以临时把日志开起来：

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

排完关掉。生产环境把错误打到页面上，比错误本身更糟。

回滚按层来，别一上来就整站恢复

单插件回滚：

wp plugin install /backup/forms-2.3.1.zip --force
wp plugin activate forms

主题回滚同理：

wp theme install /backup/theme-1.4.0.zip --force

从官方仓库装旧版本也可以用 --version=，前提是那个版本的包还在。自己留一份 zip 更保险。

下决心整站回滚之前，先把更新之后新增的数据导出来：订单、表单提交、评论、新上传的文件。回滚数据库等于把它们一起抹掉，客户那边是能感觉到的。

回滚完立刻清缓存，对象缓存、页面缓存、opcache、CDN 都要清。不清就会出现「代码回滚了但页面没变」，然后你开始怀疑回滚没生效，再折腾一轮。

几个容易踩的坑

插件之间的依赖和加载顺序。A 更新之后 hook 的优先级变了，B 的过滤器就不再生效，表现是某个字段突然不显示、某个选项突然失效。这类问题日志里先出现的是 deprecation 提示，功能坏在后面，所以更新后要看日志，不能只看页面有没有白屏。

托管环境自带的自动更新策略。有的主机默认帮你更核心小版本，你不接管它就一直在动。接管之前先确认它到底更什么、什么时候更，否则你排的窗口和它是两套逻辑。

多站点网络。逐个站点更新，先在测试子站或访问量最小的子站验证，别对整个网络一把梭。主站的插件更新影响的是全网共享的那份代码，顺序上要更保守。

更新后一周看指标。表单提交量、下单量、关键页的加载时间，和自己的前 7 天均值比。没有基线就没法判断「好像变慢了」是错觉还是真事，所以基线要在更新之前就记录下来。

留一行记录

每次更新写一行：日期、组件、版本 from→to、结果、是否回滚、谁执行的。真出问题时，这行记录是唯一能复盘的东西，也是下次排窗口时判断「这个插件历来不安分」的依据。

流程本身不用复杂，能稳定执行的最小版本就够了：固定窗口、验证过的备份、一次一个、冒烟清单、分层回滚。缺哪一环，都会在某次普通的更新里补上一课。