v3.6.6 升级当天清单：先换站点签名密钥还是先改管理员密码

升级到 v3.6.6 的当天，先轮换站点签名密钥还是先改管理员密码？顺序取决于哪一项在消除「已经存在的风险」：这次版本（2026-10-08 发布）修了两处高危——列表排序参数的 SQL 注入，和站点切换用的登录凭证可被伪造；官方的升级建议是把轮换站点签名密钥与修改管理员密码一起做。正确的当天路线是：先备份停写，再升级程序，然后轮换签名密钥、改管理员密码，最后带着两项验证清单复测。密钥轮换排在改密码前面，因为凭证伪造利用的是签名体系，程序升级加轮换之后旧伪造路径才彻底失效。

这次版本修了哪两类问题

第一类在列表排序：前台与后台的列表接口支持排序参数，问题出在参数没有完全走安全的取值路径，存在 SQL 注入风险——这类点位的特殊性是「看着是展示功能，其实是查询入口」，攻击者不需要登录也能摸到可注入的参数面。第二类在多站点切换：站点切换场景下的登录凭证机制可被伪造，v3.6.6 把这类凭证改为一次性票据的处理方向。两类合起来解释了为什么升级动作不止「换二进制」：程序更新了，签名体系还沿用旧密钥的话，历史签发的凭证理论上仍是需要清零的资产。

升级前的备份与停写窗口

动手前把退路铺好：用系统的备份能力做一次全量备份，范围覆盖数据与静态文件；备份完成后进入停写窗口，暂停批量导入与定时发布任务，避免升级瞬间有草稿或待发布内容卡在中间状态。停写窗口的长度按升级步骤实测控制在几十分钟内，选在流量低谷。多语言站点与多品牌站要把「哪些站点今天不能更新内容」提前通知到对应编辑，草稿状态的页面在窗口期内不要提交。

当天顺序：升级、轮换签名密钥、改管理员密码

第一步，升级程序到 v3.6.6，按部署方式走各自路径（面板部署或镜像部署），完成后先确认版本号显示正确。第二步，轮换站点签名密钥：这是让历史上可能已泄露签发的凭证整体作废的动作，轮换后所有旧会话自然失效，放在改密码之前做，避免改完密码再清一次会话、二次打断使用者。第三步，修改管理员密码，改的是人持有的那道门；放在轮换密钥之后，管理员用新密码建立新会话，后面验证环节顺带完成。第四步，清理浏览器端缓存的旧登录状态，其他成员重新登录。四项动作的先后是因果，不是习惯：程序、密钥、口令、会话，从机器到人为一层层换。

验证点：列表排序与站点切换

两个修复点各给一条实测路径。列表排序：到前台列表页与后台文档列表，逐个组合排序参数（时间、标题、自定义字段升降序）刷新，确认结果正常返回、日志里没有异常查询报错——这同时在复测「排序参数走安全取值路径」的修复效果。站点切换：在多站点配置下连续切换两次以上，确认每次切换都需要重新校验、切回原站点不出现免登录直通；这验证的是一次性票据的不可复用。最后跑一遍常规链路：新建草稿、预览、转正式，确认状态流转正常、回收站可进可回。

常见问题

问：不换签名密钥，只升级程序行不行？ 答：升级修复了代码路径，但历史签发的凭证不随代码更新作废；官方升级建议里轮换签名密钥与改管理员密码是成套动作，拆开做等于留了半个尾巴。

问：轮换密钥会把在线用户踢下线吗？ 答：会，基于旧密钥的会话失效、需要重新登录，所以排在停写窗口内、改密码之前，一次打断解决。

问：验证时发现排序组合仍报错怎么办？ 答：先确认是否缓存或旧模板干扰，若版本无误仍异常，暂停对外批量接口调用并按更新记录核对补丁完整度。