同一款程序的两条分支同日出安全版，站点跟哪一条要看什么

同一款程序的两条分支同日出安全版，站点跟哪一条要看的是自己所在分支的支持状态，不是版本号新旧。以 Joomla 在 2026 年 1 月 31 日同时发布 6.0.2 与 5.4.2 为例，官方说明这是给 5.x 与 6.x 两个系列的安全与错误修复版本，并且为 5.4.x 分别写了两条日期：错误修复支持到 2026 年 10 月 13 日，安全补丁支持到 2027 年 10 月 12 日。判断跟版动作时，先看这两条线，再看修复项内容。

同一天两个版本，说明的是维护结构

一个项目同时维护两条以上分支，通常意味着上一大版本还有相当规模的存量站点，官方不能只服务最新分支。这种结构下，同一天出的两个版本号内容并不相同：新分支的版本往往同时带功能修补与安全修补，旧分支的版本只回移安全修补。

因此“同日出安全版”这件事本身不告诉你该升哪一条，它只说明两条分支都还在被维护。真正决定动作的是你所在的分支还在哪一条支持期内。

先看自己站点的分支，再看日期

站点的判断顺序可以固定下来：先确认当前大版本与次版本，再查官方给出的支持日历，最后对照两条截止线。错误修复截止之后，日常使用中的小毛病不会再被官方处理，但安全漏洞仍然会出补丁；安全修复截止之后，连补丁也没有了，新出现的漏洞只能靠外部防护手段临时遮挡。

以 Joomla 5.4.x 的日期为例，2026 年 10 月 13 日之后到 2027 年 10 月 12 日之间，这一分支仍会收到安全补丁，但不会再收错误修复；这段时间适合把升级窗口排进去，而不是等到第二条线之后被动处理。

跟版时读什么内容，而不是只读版本号

版本号只表示“有更新”，是否要立刻处理取决于修复项有没有触及自己的用法。官方更新记录里的每一条描述都值得读一遍，判断逻辑很朴素：这个入口我有没有对外开、这一层我有没有定制过、被修复的行为我有没有依赖。

自家系统的做法可以直接对照。AnQiCMS 的 v3.6.6 是一次安全版本更新，更新记录里写明两项高危问题：列表排序参数的 SQL 注入，以及站点切换登录凭证可被伪造；对应的处置是把排序参数改为严格的标识符白名单，并把跨站跳转登录换成服务端签发、使用一次即失效、有固定时限的一次性票据。这类描述比版本号更有用——如果站点没有用到多站点切换登录，风险面就小；如果后台列表页对外可访问，那么这一条要优先处理。

安全版本的更新记录还会附带升级要求。v3.6.6 的提示里明确：若站点曾被入侵，仅升级不足以清除攻击者已经拿到的会话，需要一并轮换各站点登录签名所用的密钥并修改全部管理员密码。这类要求不能省略，省略等于把入口留回原样。

升级窗口怎么排

排期时把三件事按顺序写进窗口：先做一次完整数据备份，留出可回退的位置；再在非高峰时段完成升级，逐项核对更新记录里的修复点是否已生效；最后处理登录凭证与账号状态，确认管理员口令与站点密钥都已换新。两条截止线之间通常还有数月，这段时间足够把上述三步做完，不必压缩到一天里赶。

常见问题

两条分支同日出安全版，是不是说明旧分支快停了？ 不是。同日发布说明两条分支都还在维护，停止时间以官方支持日历上的两条截止日期为准。

只跟安全补丁、不跟功能更新，可以吗？ 在错误修复截止之后本来也只能这样。功能类修补不再提供时，定制改动要自己维护，直到完成大版本升级。

过了安全修复截止但还没升上去，风险怎么临时压低？ 收紧对外暴露面：关闭不必要的接口与后台入口，限制可执行管理操作的网络范围，并把备份频率提高，确保出问题时可以快速回退。临时手段不替代升级。

怎么知道某个安全版是否影响自己的站点？ 读更新记录里的修复项描述，逐项对照自己是否使用该入口或该功能。没有用到的功能可以延后，用到的入口要优先安排。

升级前一定要备份吗？ 要。升级可能触发数据结构调整与模板兼容问题，事先备份才能让回退在可控时间内完成，恢复时也要能连带静态文件一起回到原位。