自动更新开着时，大版本和小版本的默认行为差在哪

内容管理系统开启自动更新后，大版本和小版本的处理有什么不同、运维上要注意什么，是升级策略里最实际的两个问题。WordPress 的官方运维手册把默认取向写得很明确：大多数站点默认启用自动更新，范围覆盖核心、插件、主题与翻译文件四类；并且自 5.6 起，新安装对核心小版本和大版本都默认开启自动更新。对照之下，另一类设计是把升级这类全站级操作放到默认不对外开放的位置，需要显式开启才能执行——两种取向对应的是两种运维假设。

小版本自动更新在补什么

小版本通常只做三件事：修缺陷、补安全、不动结构。它的变更面小、回退成本低，所以适合被自动化。判断一段版本号是不是这一类，看的是最后那一位有没有变——前两位没动、末位递增的，一般就在这一档里。

自动补这一档的价值在于时间差：安全补丁从发布到被装上的间隔，是攻击窗口最直接的度量。人工跟进时，这个间隔取决于运维人员多久看一次公告；自动跟进把它压到小时级。

大版本为什么不宜放任自动

大版本会改的东西不属于「兼容范围内的修补」：数据结构、模板可用标签、接口形态、默认行为。这几项里任何一项变化，都可能让线上页面表现异常，而异常不一定出现在首页——更可能出现在某个低频栏目或某个表单上。

风险不对称也在这里：小版本自动失败的恢复成本低，大版本自动出问题的恢复成本取决于你有没有当次备份。所以「新安装默认对大版本也自动」这种取向，对以内容运营为主、页面结构长期不动的个人站点是合理的；对企业官网和政务类站点就不是。

两种默认取向的运维差别

差别体现在三处。第一处是节奏：全自动意味着站点变更时间由发布方决定，人工评估意味着由你的日历决定。第二处是责任：出问题时，全自动那一侧要能证明「没人看过就变了」，人工评估那一侧要能证明「看过并判断过」。第三处是能力面：把升级动作按域收在显式开启里，多站点场景下才不会出现「一个站点的运维操作影响其他站点」这种后果。

升级前的备份要包含什么

这一步比取向本身更重要。站内的备份能力覆盖数据与静态文件两层，升级前要把这两层一起带走，原因很实际：大版本变更常同时改动数据库结构与已生成的静态产物，只备份数据库不足以恢复页面表现。

三条具体做法：备份完成后核对一次可否读出，而不是只看有没有生成文件；给备份打时间标记，回退时按标记而不是按文件名排序取；把备份存放位置放在站点不可公开访问的路径，升级出问题时这份文件本身不该成为第二个泄露点。

把升级排进维护日历

一个可执行的排法：安全类小版本走自动，当天完成；功能类与结构类变更按月集中一个窗口，先在测试环境或体验站上过一遍，确认首页、列表页、文章页、表单四类页面都正常再上生产；每季度回头清理一次遗留的扩展组件，无人维护的那些按公告里「不支持」这一档处理，替换或下线，不要留在自动通道里。

常见问题

问：完全不自动是不是更稳妥？ 答：不是。安全修补的时间差就是攻击窗口，关掉自动之后必须用更短的跟进节奏补回来，而多数团队做不到。

问：Docker 镜像部署和面板部署在升级上有什么实际区别？ 答：镜像方式换的是整体版本，回退靠换回旧镜像，粒度粗但可复现；面板与命令行方式要自己控制备份与目录差异，灵活但依赖操作规范。

问：怎么知道自己站点有没有开着大版本自动？ 答：看配置文件里的对应常量或后台的更新设置项；新安装与老版本升级而来的站点，默认值可能不同，要实测确认而不是按文档推断。