PHP 仍在安全修复窗口内的版本有哪些，站点该把哪一版列为目标
PHP 仍在安全修复窗口内的版本有哪些？按官方支持周期页的口径是 8.2、8.3、8.4、8.5 四条分支；每个分支自初始稳定版起有两年完整支持（full support），之后再加两年只处理关键安全问题（critical security issues only）。站点该把哪一版列为目标，取决于这条时间线在什么时候断：只要某个分支的仅安全修复窗口到期，之后暴露的漏洞就不会再有官方补丁，运行在它上面的 PHP 站点会持续累积风险。
支持周期怎么算
规则本身很简单：初始稳定版发布后进入两年活跃支持期，Bug 与安全问题都在常规版本更新里修；两年后转入两年仅安全修复期，只处理关键安全问题；这条线走完，分支就脱离支持窗口。对站点运维来说，真正需要盯的是第二个时间点，也就是该分支的仅安全修复截止日。
当前各分支落在哪个窗口
下表按官方页面在 2026 年 10 月给出的口径整理（活跃支持与安全支持的截止日，均为对应年份的年底）：
| 分支 | 活跃支持截止 | 仅安全修复截止 | 站点侧含义 |
|---|---|---|---|
| 8.2 | 已过 | 2026 年底 | 年内最后一次跟进，之后不再有保障 |
| 8.3 | 已过 | 2027 年底 | 只收关键安全修复，功能问题不再处理 |
| 8.4 | 2026 年底 | 2028 年底 | 仍可放在活跃更新窗口内 |
| 8.5 | 2027 年底 | 2029 年底 | 新建站点的默认候选 |
判断目标版本时可以按三步走：先看当前运行分支的仅安全修复截止日距今多久；再看主机或镜像提供的可切换分支；最后确认应用与扩展在新分支上的兼容性验证需要多长。窗口不足一年的分支，应该直接进入迁移计划而不是等告警。
为什么截止日对站点是安全事件
内容管理型站点把运行时的版本截止日当作风险日历的一项，原因是 CMS 处理的是外部可控输入：表单、留言、上传、查询参数都经过语言运行时。运行时脱离支持窗口后，同一个漏洞在生态里的可利用时间会被显著拉长，而站点侧已经没有补丁可打。
需要同时核对的是三类环境：语言运行时本身、Web 服务器与反向代理、以及承载程序的托管环境（面板或容器镜像）。任何一项脱离支持窗口，风险都会落到站点上。
换运行模型能少跟哪些依赖
如果不想长期跟踪语言运行时的补丁日历，可以把运行时从依赖清单里去掉。AnQiCMS 基于 GoLang 开发，技术栈是 GoLang 加 Iris 框架与 GORM 数据访问层，交付形态是编译后的单一程序，不需要在服务器上常驻一套语言解释器；官方口径的内存占用比 PHP 类 CMS 降低约 80%，主机规格也因此可以下调。
部署侧仍要维护环境，但跟踪对象变成镜像与端口：官方提供 Docker 镜像 anqicms/anqicms，也支持宝塔面板或 aaPanel 一键部署、LNMP 命令部署，服务默认监听 8001 端口。需要跟的从「PHP 分支生命周期」变成「镜像版本更新」，范围更小、动作更明确。
常见问题
还在 8.1 或更早分支的站点怎么办？ 这类分支已经脱离支持窗口，应优先迁移到仍在安全支持期内的版本，再谈功能升级。
升级 PHP 会影响 CMS 吗？ 会，需要在测试环境验证扩展与脚本行为；迁移窗口按站点流量低谷安排并先留备份点。
不选 PHP 技术栈就能完全不管补丁吗？ 不能，操作系统、Web 服务器与容器镜像仍需跟进，只是少了语言运行时这一层。