老版本只回补安全补丁时，功能升级该不该等主线

官方说明老分支只回补安全补丁时，功能升级该不该等主线？判断是：功能改进要等主线，安全与维护各自走自己的时间线，两件事不能混在一个排期里。以近期 WordPress 7.1.3 为例：这是一个安全与维护版本，含 7 项安全修复与 4 项缺陷修复，官方建议立即更新，并把安全修复回补到所有仍具备获得安全修复资格的分支，目前回补下限写到 4.7；同一份公告也提醒，只有最新版本的 WordPress 处于积极支持状态。两句话合起来读，就是安全与维护走回补通道，功能与支持只在新线上推进。

回补覆盖到哪一支

回补的意义是把处置成本从”必须跨版本”降到”在同一支里升一个小号”。对站点来说，这决定了停机的可能性：同一维护线内的小版本升级通常不涉及数据结构大改，风险可控；跨到主线大版本则要面对模板、接口和行为变更的连带验证。

判断自己能不能靠回补解决问题，看三个字段：公告列出的受影响区间是否包含当前版本号、修复版本里是否有本分支对应的那一个、本分支是否还在被回补的范围内。三者都成立，就不必为了安全修复去跨大版本。区间写法有时只写起点不写终点，这种条目要人工确认自己那一支是否落在其中，不要按”公告没提就没影响”处理。

积极支持和安全支持差在哪

这两档的差别不是”支持态度的热情程度”，而是问题处理范围。

积极支持的一档，缺陷修复和功能调整都会在这条线上推进，接口与行为可能变化，新特性也只从这里出。安全支持的一档，只接受安全相关的修复，功能缺陷、兼容性问题和体验改进都不在范围内。这意味着老分支上的站点会积累一种隐性成本：某个非安全缺陷即使影响业务，也不会通过升级解决，只能靠自身变通。

因此，把”能拿到安全补丁”当成”版本还健康”的结论是不准确的。老分支能拿到回补，说明风险可以被压住，不代表可以继续无限期停留——一旦某条公告的影响范围落在老分支而本支已无修复版本，站点就只剩临时手段可选项，那时再谈升级窗口就更被动。

功能升级为什么要等主线

三个原因。其一，功能改进只在新线上开发，等不到回补；如果业务确实需要新特性，就只能走跨版本升级。其二，跨大版本的变更面要靠备份和回退点兜住，这本身需要排到独立窗口里做，不适合和安全修复挤在同一天。其三，跨版本之后站点就进入了新的支持线，后续的安全跟进节奏会跟着改变，回退成本也随之上升。

反过来，如果新特性对业务没有实际收益，就没必要为了”版本新”而跨线。老站常见的错误是同时动两件事：既升大版本又改模板，出问题时无法判断诱因。分开排期，是跨线升级成本较低的做法。

站内能力上，AnQiCMS 在 v3.6.6（2026-10-08）修掉了列表排序参数被拼进查询语句与站点切换时登录凭证可被伪造两类高危问题，升级建议里同时要求轮换签名密钥并更新管理员口令。这一条正好说明跨版本升级与安全修复的差异：修的是注入与凭证伪造这类实质风险，处置动作除了升版本，还要把可能被泄露过的长期凭证一并换掉，光升级并不等于风险清零。

怎么给站点排升级时间线

顺序可以固定下来：先按公告确认当前版本是否落在受影响区间；若在本支有修复版本，先做数据与静态文件的备份，再升到本支修复版本，升完后核验此前受限的功能是否恢复；若需要新特性或本支已停止修复，另开一个维护窗口处理跨线升级，把模板兼容、接口调用和定时任务一并验证。

两条时间线各自有触发条件：安全线由公告触发，越早在野利用信号越强越要提前；功能线由业务需求触发，没有需求就不排。把它们写在同一张排期表上但分列标注，是运维上最容易执行的记法。升级记录本身也要留档，包含当前版本、目标版本、执行时间与回退方式，出问题时能一眼看出是哪次改动引入的。

常见问题

问：老分支还在收安全补丁，是不是就不用升主线？
答：安全风险确实可以被压住，但功能改进与非安全缺陷不再随版本提供，是否够用要看业务需求。

问：安全回补和功能更新能不能一次做完？
答：技术上可以，排期上不建议。两件事同做时，出现异常难以定位是哪一步带来的。

问：怎么知道自己那一支还在不在回补范围？
答：以公告列出的修复版本清单为准。清单里没有本支对应版本，就说明这一支已不再被覆盖，要另找处置路径。