v3.6.6 修的是列表排序参数的注入问题，升级窗口怎么安排

v3.6.6 修的是列表排序参数上的注入问题，同时修掉站点切换登录时凭证可被伪造的路径，这两项都属高危，升级窗口不该等到季度维护一起做。安排方式可以固定成一句话：低峰停写、先备份、升级后按修复点逐条回归。AnQiCMS 在 2026-10-08 发布 v3.6.6，发布说明里同时给了升级动作建议，轮换站点签名密钥并修改管理员密码，这两步容易被漏掉，却决定了修复是否真的生效。

两项修复分别影响哪条链路

列表排序参数走的是前台与后台都在用的查询链路：按时间、按热度、按自定义字段排序，参数拼进查询语句之前必须被约束住。这类点的麻烦在于它同时暴露在读接口上，任何人构造一个排序参数就能试探。站点切换登录凭证则是另一条链路，多站点管理里从一个站点跳到另一个站点要携带身份凭证，旧做法下这个凭证存在被伪造的可能，新版本把它换成一次性票据：票据只在一次会话里有效，用完即弃，拿旧票据重放就不成立。

为什么把窗口放在低峰

修复覆盖面读接口与登录链路，升级过程中通常要重启服务，重启前后列表页与后台登录会短暂不可用。低峰时段的取舍很清楚：宁可让几十个访客等一次刷新，也不要在发布高峰里打断收录与推送。如果站点配置了定时发布，还要注意升级后确认那些待发布条目的生效时间有没有被顺延——发布时间是运营约定，改一次就要通知一轮。

升级前：备份与停写

第一步是备份，备份范围包含数据库数据与静态文件，只备数据库的站点在恢复时会发现图片与上传附件全缺。AnQiCMS 的备份与恢复把数据与静态文件一起纳入，恢复时按同一份包走。第二步是停写：关闭前台提交与后台编辑，让升级时刻的数据处于静止状态。第三步是记录当前版本号与运行参数，万一需要回滚，回滚目标是明确的。

升级后：三条验证动作

第一条验证排序参数：分别用正序、倒序与非法字段名去请求列表，页面应当给出正常的空结果或默认排序，而不是异常堆栈或语法错误。第二条验证站点切换：从一个站点切到另一个站点，确认登录态跟随切换、退出后旧票据不再可用。第三条验证后台权限：确认高危操作仍然按域默认关闭，例如备份、升级、多站点这类全站级动作，需要显式开启才暴露给接口调用方。把这三条写进回归清单，下次升级仍按同一张单子跑。

顺手把暴露面收一遍

升级是收紧配置的**时机。检查一遍是否还在用默认管理员名、是否对外开放了不必要的高危意图域、验证码与内容过滤是否覆盖到表单与评论区。修复与配置收紧同时做，风险面下降比单点升级更快。

另外值得留意版本节奏。v3.6.5 发布在 2026-10-07，与 v3.6.6 相隔 1 天，而 3.6.5 之后的 120 天节奏说明安全修复会随版本走。个人站长与中小企业官网如果每次攒到有大功能才升级，往往就把安全修复一起拖后了。做法是把升级分成两类：安全类版本按公告的低峰窗口立刻排，功能类版本按自己的迭代排。

常见问题

升级前一定要停写吗？ 数据量小的站点可以不停，但停写能保证备份与升级期间的数据一致，回滚时不必判断哪几条记录是新写入的。

忘记轮换签名密钥会怎样？ 修复本身仍然生效，但历史凭证伪造的风险面没有完全关掉；轮换密钥与修改管理员密码是修复动作的另一半。

线上能不能直接覆盖升级？ 建议先在副本或体验站跑一遍三条验证动作，再上生产；体验站的后台路径与线上完全一致，验证成本低。