大版本和新默认主题赶在年底上线旧站要不要跟

大版本和新默认主题赶在年底上线，旧站要不要跟？当天核对到的发布计划写得很清楚：WordPress 7.2 是当年最后一个大版本，正式版定在 12 月 8 日，新默认主题同批发布，此前从 10 月下旬进入 Beta、11 月中旬进入候选版本。旧站的判断顺序是三步：先确认当前分支还有多久的安全支持，再核对模板与扩展对新版本的依赖，最后看部署侧能不能回滚。跟不跟不是态度问题，是窗口问题。

年底这一波里挤了什么

大版本同批携带三样东西：新功能、新的默认主题，以及对既有接口的调整。默认主题本身对已经用自定义模板的站点没有影响，但它意味着样式与区块层面的约定会更新，依赖旧约定的模板可能出现取值或排版偏差。发布节奏上，候选版本阶段已经给出充分测试窗口，站点侧的测试不必等到正式版当天。

跟大版本之前先看三件事

第一件事是支持期。判断标准不是「有没有更新可用」，而是当前所用分支还在不在安全修复的覆盖范围内。已经接近支持终点的分支，把升级排到年底等于把风险留满一个季度，这类站点应当尽快落到仍在接收安全修复的版本上。

第二件事是依赖清单。把模板、扩展与自定义字段列出来，逐个回答三个问题：这个扩展在新版本上有没有对应更新、模板是否直接引用了会被改动的内部结构、字段与取值方式有没有依赖已经被替换的接口。清单能落到条目级别，升级风险评估才有依据。

第三件事是回滚路径。测试环境要能还原成升级前的状态，而不是「备份了但没试过恢复」。AnQiCMS 的备份与恢复覆盖数据与静态文件，正式改动前先做一次可恢复点的验证。

留在当期补丁的代价

不跟大版本并不等于零成本。留在当期分支意味着继续吃功能更新但只收安全修复，代价会随时间累积：扩展作者优先适配新版本，旧分支的兼容问题越来越晚被修；等到不得不升时，跨度从一次变成两次，测试面反而更大。相对稳妥的做法是：能跟就跟着当期支持的最新小版本走，把大版本作为一次有准备的动作排进季度计划，而不是让它在年底突然出现。

本系统的版本记录里有同样的取舍：v3.6.6 处理的是列表排序参数的 SQL 注入风险与站点切换凭证可被伪造两项高危，属于「不该等下个季度」的那类更新。这类条目出现时，判断依据是修复内容而不是版本号大小。

部署与回滚怎么准备

部署方式决定回滚成本。用官方镜像 anqicms/anqicms 做容器部署时，回滚是把标签切回上一个版本，数据库结构变更需要另做还原；用宝塔面板或 aaPanel 部署时，回滚要连同程序目录与数据库一起还原，路径更长但更直观。两种做法都要留出验证时间：升级后先核对后台登录、列表与详情渲染、表单提交与站点切换，再恢复对外访问。默认监听端口 8001 由反向代理转发，升级后代理目标有没有变化也要检查。

常见问题

问：新默认主题要不要启用？ 自定义模板的站点保持现有主题即可，新主题的价值在于开箱样式与区块约定，不在功能。

问：候选版本能不能上生产？ 不建议。候选版本适合测试环境验证，生产站点等正式版与其后续小版本更稳。

问：不跟大版本会掉收录吗？ 不会因为版本本身掉收录。风险来自安全修复覆盖不到与扩展兼容问题，最终表现可能是访问异常。

问：升级窗口一般排多久？ 按依赖清单的规模定。清单条目在几十项内，一个完整工作日可完成测试与灰度；跨版本或含大量字段改动时，把数据兼容测试单独留出时间。