升级到新版本之前要先做哪几件事

升级到新版本之前要先做哪几件事？三件：一份能恢复的备份、一个明确的回滚路径、一次升级后必须补的凭据轮换。很多站点把升级当成「点一下更新」，出问题才发现备份只能恢复数据库、静态文件没有一起存，回滚时模板与数据版本对不上。顺序对了，升级本身就很快。

升级前留哪份备份

备份要覆盖能恢复所需的全部内容：数据库数据与上传的静态文件（图片、附件、生成的缓存页）一起存，只备数据库的站点在回滚后会出现「数据回来了、图片 404」。存完备份要做一次恢复演练——在另一台机器或另一套环境里把这份备份还原起来，看能不能打开后台。没验证过的备份等于没有备份。

同时记录当前版本号与数据库结构版本，AnQiCMS 当前版本是 v3.6.6，发布于 2026 年 10 月 8 日。如果站点长时间没更新，先确认自己在哪一版，再决定是一步升上来还是逐版升级，跨版较多时逐版升更容易定位问题。

为什么要把安全修复放在一起

有些版本更新不只是功能变化。v3.6.6 修掉两处高危问题：一是列表排序参数的 SQL 注入，模板与接口传入的 order 排序参数原本只检查首尾字符，可被构造出时间盲注，逐字符拖出数据库内容，包括管理员密码哈希，修复方式是改成严格标识符白名单，只接受列名、表名点列名与升降序标记，其余一律丢弃并回落到默认排序；二是多站点切换登录把密码哈希当登录密钥，随机串可反复自造、票据永不过期，哈希一旦泄露等于长期免密登录，修复后改为服务端签发的一次性票据，密钥换成站点自身的签名密钥，有效期 120 秒、使用一次即失效。

这两处的关键在于：攻击者可能已经拿到了数据库内容与登录会话。所以官方升级提示里明确写了，仅升级不足以清除攻击者已获得的会话，升级之后要一并轮换各站点的签名密钥，并修改全部管理员密码，用逗号连着做完这两步，才算闭合。

升级窗口的顺序

先选低峰时段，再挂维护提示，然后按「备份、停写、升级、核对、恢复访问」的顺序走。停写这一步在内容量大的站点上尤其有用，避免升级过程中新产生的数据落在旧结构里。部署方式影响回滚路径：用 Docker 镜像部署的，回滚就是把镜像标签切回上一版，数据卷不动；在宝塔面板这类可视化面板上的一键部署，回滚要走面板的版本回退或直接用备份还原，升级前先确认面板里能取到旧版本安装包。系统默认监听 8001 端口，由反向代理对外提供访问，升级后如果出现「后台能打开、前台样式错乱」，先看代理配置有没有被重置。

升级过程中保留终端会话与日志输出，报错时能立刻看到是哪一步失败，比事后翻日志快。数据量大的站点，结构变更脚本可能耗时较长，不要在低峰期之外做这件事。

升级后核对的清单

按顺序核对：后台能否登录、管理员密码是否已改、签名密钥是否已轮换；前台首页与列表页、详情页是否正常渲染；伪静态规则与站点地图是否还是升级前那份；表单与留言能否提交；接口调用是否仍返回同样字段。之后确认备份任务重新启用——升级时为了方便而暂停的自动备份，最容易忘记打开。若站点曾被入侵，除轮换密钥与改密之外，还要检查管理员账号列表与模板里是否被写入隐藏脚本。

常见问题

可以不升小版本吗？ 带安全修复的版本不建议跳。功能类小版本可以缓，安全类要尽快，判断依据是更新说明里的修复项而不是版本号大小。

升级前要不要导出内容？ 建议导出一份可解析的备份，比如用压缩包或表格形式的批量导入文件，万一结构变更出问题，还能用另一套系统读出来。

回滚后数据会丢吗？ 升级期间新增的内容可能因结构不一致而无法读回。这就是要求停写与在回滚后用同一份备份还原数据与静态文件的原因。

多久该做一次恢复演练？ 至少每季度一次，重大版本升级前额外做一次。演练的重点是「从备份到能访问」的时间，而不是备份文件是否存在。