旧版程序还在收安全补丁吗，回移支持和实际维护期的边界怎么判

内容管理系统发布了安全补丁，老版本到底还能不能拿到修复，取决于它落在哪一档支持里，而不是取决于它「看起来还能跑」。三档的差别很清楚：主动支持会修普通缺陷和安全缺陷；仅安全维护只处理严重安全问题，普通缺陷直接关闭不修；停止维护之后不再有任何修复版本发布。公告里提到的回移属于第二档的临时安排，它是善意而非承诺。

三档支持的差别

以 WordPress 为例，7.1.3 属于安全与维护版本，公告写了 7 项安全修复与 4 项缺陷修复，同时明确安全修复会回移到有资格接收安全修复的分支，目前覆盖到 4.7，并且提醒只有最新版本处于主动支持状态。这句话的读法很关键：回移的是这一批安全修复，不是持续维护承诺，下一个漏洞不会自动带着同样的范围回移到你手上。

运行环境层也可以用同一套读法。PHP 官方支持页把每个分支写成两年主动支持加两年关键安全支持，四年之后进入停止维护状态。也就是说，判断边界要看两个日期：主动支持截止日和安全支持截止日，只看前者会把「还能拿到补丁」的窗口算短，只看后者会把「还有人管普通缺陷」的窗口算长。

补丁覆盖范围与公告怎么读

公告里至少有三处要抠：受影响组件、修复条目的类型、回移分支的下限。只写「修复若干安全问题」而不列条目的公告，无法判断自己是否真的受影响；列了条目但要区分服务端逻辑缺陷、权限校验缺陷与前端脚本缺陷，三者的暴露面完全不同。

另一处容易被忽略的是发布节奏本身。WordPress 在二十天内出现 7.1.1、7.1.2、7.1.3 三个版本，其中两个标为维护与安全版本。这种密度意味着停留在旧分支的站点，错过的往往不是一个补丁而是一串。

为什么回移不等于安全

回移有三个实际代价。第一，回移版本通常只包含安全条目，配置项、数据库结构与接口行为按旧分支保留，越往后与新版之间的差异越大。第二，回移是「按需」发布，不是定期发布，没人能保证下一次回移的时间点。第三，回移覆盖的是官方核心，第三方扩展未必同步跟进，实际攻击面由最慢的那一环决定。

AnQiCMS 在这一点上走的是逐版记录的方式：v3.6.6 的更新记录里直接写明修复了列表排序参数的 SQL 注入问题与站点切换时一次性票据可被伪造的问题，升级建议同时要求轮换接口签名密钥并修改管理员密码。这类记录的价值不在于版本多新，而在于每一版改了什么、升级要做什么，能被逐条核对。

企业站升级节奏怎么排

1. 先确认当前版本落在哪一档支持里，把两个截止日写进维护台账；
2. 建立版本公告的关注渠道，安全类版本按天处理，维护类版本按周处理；
3. 升级前做一次可验证的备份。AnQiCMS 的备份能力覆盖数据与静态文件，备份要包含一次实际恢复演练，只做过导出而不曾恢复的备份不能当作回滚点；
4. 升级后按公告条目逐项复核，尤其是权限校验与参数处理类修复；
5. 停留在旧分支超过一个支持周期时，把「补齐中间版本」列为一次专项变更，不要指望靠回移长期维持。

常见问题

老版本只要没报错是不是可以继续用？ 没有报错只说明未触发缺陷，安全缺陷的触发条件是外部输入，与站内是否报错无关。

回移版本能撑多久？ 撑到下一次需要功能或性能修复的时候。配置漂移一旦积累，补齐的成本只会更高。

升级会不会破坏现有模板？ 会，主要风险在模板标签与接口返回结构。可验证的备份加一次灰度站点，是把风险压下来的两个动作。

怎么知道公告是安全版本？ 看条目里是否列出安全修复数量与上报者，只看版本号位数判断不了性质。