安全修复回溯到很多个老分支，还在用老版本的站点要不要跟着动

安全修复回溯到很多个老分支时，还在用老版本的站点仍然要跟着动，但不能把「有回溯包」理解成「我的版本还在被支持」。WordPress 在 7.1.4 的说明里把两件事分得很清楚：出于礼遇，本次安全修复被 backported 到所有仍在接收安全修复的分支，目前一直到 4.7；同页同时写明 only the most recent version is actively supported，且回溯包是 in progress、就绪后才陆续发布。这两个口径的差别，正是老版本站点排期时最容易读错的地方。

回溯修复与主动维护是两件事

回溯是单次动作，只覆盖这一批被修复的缺陷，且发布时间滞后于主线；主动维护是持续状态，包含后续所有修复、结构演进与兼容跟进。对站点来说，差别体现在三个地方：回溯包的到达时间不确定，可能要等；回溯只补本次漏洞，下一次披露时能否继续拿到，取决于该分支是否仍在接收安全修复的范围内；老分支上的缺陷与功能问题不会再被顺手修掉，报上去通常也只会得到「请在受支持版本复现」的回复。

老版本还缺什么

除修复通道之外，老版本缺的通常是三样。其一是新的防护手段：内容系统的防护思路会随披露的缺陷类型演进，AnQiCMS 从 v3.6.5 到 v3.6.6 的两次更新里，前者重建了 MCP 工具层与回合级批量审批，后者修掉列表排序参数的 SQL 注入与站点切换登录凭证可被伪造，这两条都属于新版才有的收口方式，老版本拿不到。其二是配置与运维能力的补齐，比如备份覆盖范围、缓存与静态文件处理。其三是依赖链，运行环境与组件的兼容版本会逐步和老主线脱钩，等真要升级时可同时替换的东西更少。

排期时按什么顺序动

先按暴露面判断这一批回溯包要不要现在装：缺陷是否需要登录才能触达、站点是否用了受影响的功能、有没有已在野利用的迹象。三项都指向高危时，当天装回溯包，不要等主线。装完之后再谈迁移，顺序上把升级分成两级：能升到同一大版本的最新小版本，先做这一步，风险低、收益立竿见影；跨大版本的迁移单独排窗口，先在隔离环境上验证。AnQiCMS 当前版本是 v3.6.6，2026-10-08 发布，官方升级建议里包含轮换站点签名密钥与修改管理员口令，说明版本更新与凭证处理要放在同一个窗口内完成，不要把密钥轮换单独推到下周。

迁移期间的兜底

迁移排期落到日历之前，兜底动作要先生效。其一，把备份做扎实并验证可恢复，AnQiCMS 的备份与恢复覆盖数据与静态文件，回退点必须包含模板与附件，否则升级失败时只能重建。其二，收窄可达面：暂时关闭不用的写入口，评论与留言按需要加验证，把暴露面压到迁移完成。其三，把日志留够时长，迁移完成后至少回看披露日到升级日这段时间有没有异常命中。其四，如果分支已彻底不在接收安全修复的范围内，兜底要换思路：把站点收进更前置的防护层，并把迁移优先级提高到本窗口内必须完成。

常见问题

官方发了回溯包，是不是可以推迟迁移

可以推迟「紧急迁移」，不能取消「计划迁移」。回溯包解决本次披露，但下一次漏洞的到达时间不由你决定，而分支能否继续拿到修复由官方支持范围决定。

怎么确认自己那个分支还能不能拿到修复

以发布说明与支持范围为准，不看二手转述。像 7.1.4 这种说明里会直接写回溯覆盖到哪条分支，以及只有哪个版本在主动支持范围内，这两句话就是判断依据。

迁移到新版本最大的风险是什么

数据结构与模板行为的变化。兜底办法是在隔离环境上跑一次完整验证：登录、列表分页、栏目与文章页、附件与搜索各走一遍，并确认可从备份干净恢复后再上生产。