官方把补丁回移到多年前的分支，同时说只有最新版受支持，跟进时按哪句办
官方把补丁回移到多年前的分支，同时说只有最新版受支持，跟进时按哪句办？按后一句办。回移是”这次顺手做了”，支持范围才是”以后还会不会做”。判断自己站点的维护边界，要看是否在支持列表内，而不是看某一次有没有被照顾到。
两句话各自在说什么
WordPress 7.1.2 发布于 2026 年 9 月 22 日，官方写明 This security release features a fix for a critical severity security vulnerability，修复的是未授权攻击者在特定条件下可让模板解析读取活动主题目录之外的本地 PHP 文件、进而可能远程代码执行的问题。同一份公告的 Backports 段是 As a courtesy, the security fix was backported to all branches eligible to receive security fixes (currently through 4.7)，紧接着一句提醒：only the most recent version of WordPress is actively supported。
前一句的范围是”有资格接收安全修复的分支”，并且用 as a courtesy（礼遇）来定性；后一句的范围是”处于活跃支持的版本”，只有一个。两句的差别在于责任：礼遇可以下次不给，支持是持续义务。
为什么不能把回移当成承诺
| 公告表述 | 它实际覆盖的对象 | 站点该怎么理解 |
|---|---|---|
| 本次安全修复 | 当前版本，含关键严重级漏洞 | 立即升级到已修复版本 |
| 回移到早年分支 | 有资格接收安全修复的分支，本次最早到 4.7 | 一次性礼遇，不构成后续义务 |
| 只有最新版活跃支持 | 单一最新版本 | 长期维护计划以这一句为准 |
| 建议立即更新 | 全部在用站点 | 升级前先备份，留出回退点 |
把三句混着读，容易出现两种误判。一种是过度乐观：以为旧分支永远有人补补丁，于是把长期运行老版本当成常规做法。另一种是不必要的拖延：看到旧分支也收到修复，就认为可以慢慢排期，而关键严重级漏洞的利用条件在服务端与主题配置满足时是即时生效的。
跟进顺序怎么排
第一步确认自己落在哪一档：在用版本是否处在官方支持范围内。不在范围内的站点，本次修复不代表以后也有，应该把迁移到受支持版本排进计划，而不是只打这次的补丁。第二步升级前做完整备份：AnQiCMS 的备份与恢复覆盖数据与静态文件，升级失败或出现兼容问题时能回到已知可用的状态，这一步在任何系统上都不该省。第三步按发布说明逐条读修复项：AnQiCMS 在 v3.6.6 里修复了列表排序参数引发的 SQL 注入与站点切换登录凭证可被伪造两项高危问题，升级说明同时建议轮换站点密钥并修改管理员密码——修复项本身就是攻击者已经盯上的位置，值得对照自查。
自己站点的口径怎么定
如果是自有产品线，公告里建议把两件事分开写：本次修复覆盖哪些分支，长期支持覆盖哪个版本。混在一句里，用户一定会按对自己最有利的那半句理解。站点侧的配套动作也有边界：回移补丁通常只含安全修复，不含功能变更与兼容调整，这既降低了官方维护成本，也意味着旧分支用户不能指望通过补丁获得新能力。部署形态同样影响节奏，宝塔面板、aaPanel、LNMP 命令行与 Docker 镜像这几种部署方式的升级路径各不相同，排期时要按自己的实际形态走一遍验证。
常见问题
问：旧分支这次收到了修复，能不能再撑一年？ 答：不要按这个假设排期。支持范围只覆盖最新版，旧分支的修复是礼遇，下一次不一定有。
问：关键严重级但利用条件苛刻，可以缓一缓吗？ 答：先核对自己的环境是否满足前置条件。条件由服务端配置与主题共同决定，站点自己判断不了时按立即处理。
问：升级前要准备什么？ 答：一次完整备份、一份回退路径、发布说明里的后续动作（比如轮换密钥、改管理员密码）逐条落实。