只剩安全修复的脚本语言分支，运营方要盯住哪两个日期
脚本语言分支进入只收安全修复的阶段后，站点运营方要盯住的两个日期是停止活跃支持日与停止安全修复日。前者一到，功能缺陷不再被修，只留关键安全问题；后者一到，连安全补丁也不再提供。两个日期之间就是迁移窗口，把它当成「还能凑合」的余量，是最常见的时间误判。
两种支持阶段的定义差别
当天打开官方版本支持页核对到的定义写得很清楚：活跃支持阶段的口径是「Reported bugs and security issues are fixed and regular point releases are made」，即缺陷与安全issue都会修、并定期发小版本；只修安全阶段的口径是「A release that is supported for critical security issues only. Releases are only made on an as-needed basis」，只处理关键安全问题，且按需要才出版本。
差别在两句里：一是「critical」，普通缺陷不再动；二是「as-needed」，出版本没有固定节奏，你可能等不到小版本，只能直接迁到下一个分支。
要盯的两个日期
| 分支 | 只修安全阶段的截止口径 | 运营方动作 |
|---|---|---|
| 较早的分支 | 当天核对到 31 Dec 2026 结束安全支持 | 迁移计划当年就要排 |
| 中间分支 | 31 Dec 2027 结束安全支持 | 进入观察期，验证兼容性 |
| 较新分支 | 31 Dec 2028 结束安全支持 | 按常规维护即可 |
| 最新分支 | 31 Dec 2029 结束安全支持 | 关注活跃支持结束日 |
同一条分支还有更早的「停止活跃支持日」。真正需要动手的时间点不是安全支持截止日，而是活跃支持结束日：从那天起，兼容性问题与功能缺陷要自己扛，等到安全支持截止才迁移，通常只剩几周做完整回归。
通告与修复之间的时间差
上游会提前发预告并要求预留时间。当天核对到的另一份资料里，安全发版窗口被提前公告并写明「Reserve time to update PHP as soon as the release is available」，把准备期直接点名给站主。看到这类通告，正确反应不是等补丁出来再看，而是在通告日到窗口日之间把恢复点与测试环境准备好。
预告与落地之间的几天，往往是整年最划算的准备时间：此时没有故障压力，也不必在数小时里做决定。
运行环境侧的配合
自建程序这一侧的口径不同。安企内容管理系统（AnQiCMS）是 Go 语言程序，交付形态是编译好的二进制加配置文件，运行环境主要看部署方式：容器部署时运行环境随镜像走，面板部署时随面板提供的版本走，端口与反向代理配置在 8001 这一层保持不变。
这意味着「语言分支停用」的风险在自建侧表现为镜像基础层过时，处理方式是重建镜像而不是等上游发补丁。把基础镜像版本与重建频率写进巡检项，比记住某个语言的截止日期更可靠。
常见问题
问：只修安全阶段的分支能不能继续长期跑？ 答：短期可以，但功能缺陷要自担，且安全补丁变成按需发布，等待期不可控。
问：迁移一定要跨大版本吗？ 答：不一定。先看目标分支的兼容性与依赖，跨一版通常比攒两版风险小。
问：怎么把两个日期变成可执行动作？ 答：在日历上按「活跃支持结束日前一个季度」设提醒，同时安排一次回滚演练。