预览版要不要装到生产站，Release Candidate 和正式版怎么选

预览版不要装到生产站。Release Candidate（候选版）在发布流程里的位置是”正式版打包前的最后一次公开验证”，官方发布它的诉求通常直接写在标题里：让测试者验证最终安装包。生产站需要的是经过这段验证之后的正式版本，以及针对已发布版本的安全修复。

候选版处于哪一步

从近期 Joomla 的公告列表可以看到两条并行线索：一条是 6.2 Release Candidate，创建于 2026 年 9 月 29 日，用途写着供测试最终安装包；另一条是 6.1.4 与 5.4.9 的安全与缺陷修复发布，同时覆盖 5.x 和 6.x 两个系列。这两条线索对应两类人：前者面向愿意承担验证成本的用户，后者面向所有需要安全修复的站点。

一个健康的发布节奏里，候选版与安全修复是互补关系而不是替代关系。候选版解决”新特性是否可用”，安全修复解决”当前可访问的版本是否有已知风险”。生产站的排期应该跟着第二条线索走。

为什么不适合直接上生产

候选版的定义就是”还会变”。从候选版到正式版之间，通常还会吸收测试反馈做修改，这带来两个具体问题。

第一是数据格式与结构变更可能未定稿。内容系统的升级往往带着数据库脚本，脚本顺序跑到一半失败时，站点会停在半升级状态。提前装了候选版，等于把这类变更风险放到真实数据上执行。

第二是回退路径不清晰。装过候选版的站点要退回正式版，需要确认结构是否被改动过；改动过就得靠备份恢复，而不是简单的版本降级。生产站的恢复点越少越好，这一步没必要主动增加。

正确的用法是把候选版安排在预发环境：用一份生产数据的副本跑一遍升级脚本，检查栏目结构、模板渲染和插件兼容情况，把发现反馈出去。这样既拿到了提前验证的收益，又不把线上暴露在未定稿的变更上。

双版本线并行时先升哪一支

同一时间存在多条维护线时，判断顺序是这样：先确认自己当前版本所在的那条线是否仍在被积极支持；再看公告里的修复版本是否覆盖本线；如果本站所在的老线只拿安全补丁、不拿功能更新，那么升级目标就按安全线定，不要顺手把功能线也跨过去。跨大版本的升级留到独立的维护窗口处理，和安全修复分开排期，出问题时才能判断是哪一步造成的。

AnQiCMS 的部署方式覆盖宝塔面板、命令行与 Docker 镜像，Docker 场景的升级动作相对可控：镜像换标签、容器重启，失败时可以直接回到原标签。面板或命令行部署的站点，回退要依赖事先做好的备份，这也是为什么备份要放在升级动作之前而不是之后。

升级前必备份和回退点

系统支持数据与静态文件的备份和恢复，升级前把这条能力用起来，最少要做三件事：一是在改动前完成一次备份，并把上传目录与静态文件一并带走，只备份数据库不足以恢复被改动过的模板与图片；二是记下当前版本号与本次目标版本号，方便比对更新记录里的结构变更；三是给回退留出验证步骤，恢复之后要能打开前台页面与后台列表各一项，而不是只看进程起来了。

时间窗口上也别偷懒。候选版发布之后的几天里，正式版本身可能还带着未被发现的问题，把升级安排在公告之后、而不是公告当天，能让第一批反馈把明显问题暴露出来；反过来，安全公告确认已被在野利用的修复不适用这条经验，那种情况要在备份完成后尽快升级。

常见问题

问：只是想看新功能，能不能在测试站装候选版？
答：可以，测试站正是它的用途所在。装之前同样做一次备份，便于对照测试结果。

问：正式版发布当天要不要立刻跟上？
答：非安全类的正式版可以等一两个工作日；带安全修复的版本在备份就绪后尽快升。

问：装过候选版怎么回到正式版？
答：先核对结构是否被候选版的升级脚本改动。改动过就按备份恢复再装正式版，没改动过则直接升级到同号正式版。