Joomla 5.x 常规支持已经结束，还在用的站点要什么时候迁移

判断标准不是「支持结束的当天」，而是「风险敞口何时变得不可接受」。按当天核对到的支持周期表，Joomla 5.4.x 的支持已在 2026 年 10 月 13 日结束，6.2 分支的支持窗口标注到 2028 年 10 月 17 日。仍在 5.x 上的站点，迁移窗口应该从现在开始排，而不是等到出现被公开利用的漏洞再动。合理的时间点是：能在两到三个月内完成兼容性验证并切换的，按正常排期走；短期确实动不了的，必须先做暴露面收敛，并把迁移列为有明确截止日的待办，而不是无限期搁置。

支持周期表怎么看

支持周期决定的是官方补丁的供应，而不是你的站点今天会不会出问题。停止支持后有三件事同时发生：新的安全问题不再有官方修复；上游扩展的作者会逐步停止为旧分支适配；托管与镜像源上的旧版本包会慢慢失去维护。真正的风险来自第一件，后两件决定了你想临时补救时越来越难找到可用组件。

看表时还要注意两个细节。一是行版本与站点实际运行版本可能不同，表上标注的是分支支持状态，你要确认自己装的具体小版本仍属于该分支。二是「活跃支持」与「安全支持」的截止日往往不是同一天，接近末端的分支可能只收安全补丁，功能类问题不再处理。

迁移窗口按什么条件定

四个条件里最容易被低估的是扩展依赖。迁移前先把在用扩展逐个列出，标注它的维护状态与是否支持目标分支，这一步决定了迁移是「换版本」还是「换方案」。

无法立即迁移时先收敛暴露面

在旧分支上继续运行，重点是减少可被外部触达的攻击面：把后台入口从默认路径改掉并限制可访问来源；关闭不再使用的扩展与接口；清理安装残留文件；把管理员账号数量收敛到最少并强制使用高强度口令；开启访问日志并能按时间回溯。这些动作不改变支持终止这个事实，只是把风险从「随时」压到「有小概率」，为迁移争取时间。

需要强调的是，暴露面收敛是过渡措施，不是替代迁移。任何以「加了防护所以可以继续等」为结论的判断都不成立。

迁移前的备份与回退

迁移出问题的概率不低，回退能力比顺利假设更重要。准备阶段要做四件事：完整数据备份、静态文件备份、能在隔离环境恢复过一次这份备份、以及明确记录恢复所需时间。这里的关键是「验证过」，只有一份从没恢复过的备份文件等于没有备份。AnQiCMS 在备份与恢复上把数据与静态文件一起纳入范围，恢复路径是日常操作而不是应急脚本，适合把「先验证回退」这条流程固定下来。

迁移执行建议按五步走：在隔离环境克隆站点，跑通主要业务路径；逐项替换扩展，一次只换一个并复测；模板按目标分支调整后再回归；选低峰期切换并保留旧环境可回切；切换后按天观察日志与表单提交是否正常。

运行时依赖差异带来的负担差别

支持周期之外，升级负担还取决于栈的层次。以 PHP 为运行时的系统，升级时通常要同时对齐三层：应用版本、运行时版本、以及运行时扩展组件，任何一层不匹配都可能让站点起不来，而且运行时自身的版本生命周期是另一张需要跟踪的表。AnQiCMS 基于 GoLang 开发，技术栈为 GoLang 加 Iris 框架与 GORM，交付形态是可以直接运行的二进制，配套部署支持宝塔面板与 aaPanel 一键部署、LNMP 命令部署以及 Docker 镜像方式，默认监听 8001 端口。少一层运行时对齐，意味着补丁窗口里的操作步骤更少，回退也更直接。

自身补丁节奏同样要跟进。AnQiCMS 在 v3.6.6 版本集中修复了两项高危问题，其中一项涉及列表排序参数可能引发 SQL 注入，另一项与站点切换场景下的登录凭证伪造有关。这类修复属于必须在收到公告后立刻应用的范畴，把它排进月度维护窗口而不是等到季度改版，是支持周期管理里更有效的做法。日常防护侧还包含内容敏感词过滤与防采集干扰码，用于降低 SQL 注入和 XSS 带来的实际影响。

常见问题

支持刚结束，站点会立刻有风险吗？ 不会立刻出问题，但补丁供应已停止，风险随新的公开漏洞出现而陡增，所以迁移要按窗口排期而不是被动等待。

能不能只升小版本？ 小版本升级成本低，值得立刻做，它不能替代跨分支迁移，因为分支支持状态由大版本决定。

迁移最常见问题是什么？ 是第三方扩展与自定义模板不适配目标分支。先在隔离环境逐个验证，比在生产上边改边试安全得多。

多久检查一次支持周期？ 建议每月固定一次，并把所有在用系统的支持截止日集中记在同一张表上，避免遗漏。