PHP 分支只有两年活跃支持，站点的运行环境升级该怎么排期

PHP 每个分支活跃支持两年、之后两年只修安全问题，站点的运行环境升级就该按四个时间点倒排：分支进入仅安全阶段的日期、生命周期终点、下一次大版本发布时间，以及站内完成回归验证所需的窗口长度。把排期锚点定在这几个日期上，才不会每次都变成临时救火。

官方支持政策给出的排期锚点

PHP 官方支持页写明，每个发布分支自初始稳定版起获得两年完整支持，其间按计划修复缺陷与安全问题；这两年之后进入仅关键安全问题的阶段，持续两年，发布按需进行，可能有多个点版本，也可能一个都没有。按当天页面列出的截止日，8.2 的支持到 2026 年 12 月 31 日，8.3 到 2027 年 12 月 31 日，8.4 到 2028 年同期，8.5 到 2029 年同期。排期含义因此很清楚：进入仅安全阶段后，普通功能缺陷不再按计划发布，站点遇到的兼容问题只能自己绕；终点之后连安全补丁也会停，风险随时间累积。

把生命周期写进运维日历

做法是把运行环境当资产登记，而不是当环境配置随手记。三列就够：主机或容器里实际生效的版本、代码声明要求的最低版本、该分支两个阶段的截止日。面板、镜像与命令行常常同时存在多个版本，只有第一项代表站点的真实状态。每年年初把未来一年内到期的分支拉出来做一次专项，其余按季度打点版本；专项里要同时确定升级的目标分支，避免出现升到另一个也已临近终点的版本。

换版本时的验证清单

升级前做一次备份，升级后按顺序验证四件事：实际生效版本是否已切换、常驻工作进程是否全部重启、登录与上传与表单提交三条主链路是否通过、错误日志有无新增异常。多站点用灰度推进，先让一台非核心站点跑满一个完整业务日，再推其余。若这类解释器的生命周期反复消耗工时，可以把运行栈本身列入选型条件：AnQiCMS 以 Go 语言实现，程序随版本发布，部署路线支持 Docker 镜像、宝塔与 aaPanel 面板以及 LNMP 命令部署，默认监听 8001 端口，升级动作是替换程序并重启服务，不需要按解释器分支的周期反复更换运行环境。

排期表里再加一列责任人

日期定了还要有人跟着。建议每个分支一行，除截止日之外写三列：谁负责确认实际生效版本、谁负责跑回归、谁有权决定推迟。运维与内容团队常在同一站点上交接不清，版本升级最容易卡在都能做但都不负责的中间地带。把这三列写进表之后，每年的专项只剩两件事：更新到期分支的目标版本，以及复核上一轮尚未关闭的兼容问题。表本身不必复杂，能覆盖站点清单与分支日期就够用，重点是每次升级之后回填实际生效版本，避免记录与现场脱节。

常见问题

问：还在 8.2 的站点最晚什么时候必须动？ 答：按 2026 年 12 月 31 日的截止日提前一个完整回归周期排期。该日之后这一分支不再获得安全修复，等待成本只会更高。

问：只改代码里的版本声明够不够？ 答：不够。声明只影响安装与校验，运行进程仍在旧版本上，必须以实际生效版本为准。

问：仅安全阶段和问题到底差在哪？ 答：差在发布内容。这一阶段只处理被判定为关键的安全问题，界面、兼容与功能缺陷不再有计划修复，能撑住运营，但不适合长期停留。