老版本停止常规修补只留安全修补，升级窗口怎么排

老版本停止常规修补只留安全修补，升级窗口怎么排——先把两个时间点分开。以主流开源系统的公开路线图为例，某大版本在当年十月十三日结束常规缺陷修补，但到次年十月十二日才结束仅安全修复，中间这一年里它只出安全补丁，功能问题不再修。这意味着「还在被修补」不等于「还在被维护」，排窗口的依据是支持周期表上的两个日期，而不是当前版本号还能不能用。

两类修补差在哪

常规修补覆盖功能缺陷：界面错乱、编辑流程里的边界问题、与新版扩展的兼容异常。安全修补只覆盖可被利用的漏洞。两者分开之后，老版本会出现一种典型状态：安全上仍然有兜底，但日常使用中的小毛病从此不再修，只能靠绕过或降级操作习惯来忍受。

判断自己的位置很简单：在路线图里找到所在大版本，对照两个日期，落在哪一段就按哪一段排。

排窗口的先后顺序

窗口顺序按「风险 × 影响面」来排，而不是按版本号新旧。第一步把站点分组：内容量小、转化路径短的站点先做，用来验证升级流程本身是否可行；第二步排业务关键站点，避开内容发布高峰与促销期；第三步才是几乎不再更新的存档型站点，它可以等前两步把流程磨合完。

时间窗口的选取也有讲究。上游通常有固定的安全发布节奏，比如每月某个周三作为安全发布窗口；把自家升级安排在这些固定窗口的同一批处理里，可以减少停机次数。带广告、带活动页的站点还要避开活动期，一次升级带来的兼容问题如果撞上流量高峰，处理成本会成倍上升。

升级前的备份与回退

升级前必须做一次完整备份，而且不能只备数据库：静态文件、上传目录、模板都要在备份范围内，数据与静态文件的完整备份才能支撑真正的回退。备份做完要验证能恢复，未验证过的备份不能当回退手段用。

部署方式决定回退速度。用容器镜像部署的站点，回退更接近「换回上一个镜像」，分钟级就能完成；用面板一键部署或传统环境部署的站点，回退要重新拉代码、恢复依赖，耗时更长，因此窗口要预留更多缓冲。同一批多站点升级时，把容器化的站排在前段，能更早暴露流程问题。

高危能力在升级窗口里要保持默认关闭。全站级操作——备份、升级、多站点管理这类入口——默认不对外开放，需要在窗口内显式开启、窗口结束就收回。升级涉及接口与登录态变更时，还要顺手收紧：把访问入口相关的密钥轮换一次，管理员登录口令更换一次；核对列表查询里的排序参数不存在可被拼接的入口，涉及站点切换的登录凭证要有过期机制或一次性票据。当前版本 v3.6.6 的安全修复正是这两类问题，属于升级收尾的标准项，而不是额外加固。

常见问题

只留安全修补的老版本能不能再等一年？ 能不能等取决于功能问题是否已经在影响使用。安全上还有兜底，但功能缺陷不再修，编辑流程里的兼容问题会累积，且扩展与主题可能先行离开老版本。

要不要跳过中间版本直接升到大版本？ 按官方支持周期判断。仍在常规修补期内的版本可以先留；已进入仅安全修补期的版本，应把它的大版本迁移排进最近的窗口，而不是等支持完全结束后应急升级。

升级窗口当天出问题怎么办？ 立即回退到备份点，不要在窗口内现场修复。事后把兼容问题记录归档，下一个批次前先在小站点复现，再决定推进节奏。