只留安全修复不算停止支持，运行环境排期该按哪个时间点
PHP 版本进入只留安全修复阶段后，站点运行环境排期该按哪个时间点——答案是按活跃支持到期日倒推，而不是按最终停止维护的那一天。官方版本支持页当天的表格里，PHP 8.2 的活跃支持止于 2024 年 12 月 31 日、安全支持止于 2026 年 12 月 31 日；PHP 8.3 活跃支持止于 2025 年 12 月 31 日、安全支持止于 2027 年 12 月 31 日；PHP 8.4 活跃支持到 2026 年 12 月 31 日、安全支持到 2028 年 12 月 31 日；PHP 8.5 活跃支持到 2027 年 12 月 31 日、安全支持到 2029 年 12 月 31 日。很多团队把排期写在最后一列那天之前，结果整个窗口都处在一个只修安全问题的分支上。
两阶段支持的区别落在哪类问题上
| 阶段 | 还会修什么 | 不再修什么 | 站点会碰到的现象 |
|---|---|---|---|
| 活跃支持 | 功能缺陷与安全漏洞 | 无 | 兼容问题有官方补丁可跟 |
| 只留安全支持 | 安全漏洞 | 功能缺陷、依赖适配 | 扩展报错只能自己绕，行为差异不再改 |
| 停止维护 | 无 | 无 | 新漏洞不再发布补丁 |
差别平时看不见，一旦碰到就集中出现：与新版数据库或扩展的兼容问题不再有人修；某个上游库改了行为，官方分支不再跟进；而安全修复仍会照常发布，所以「还在收补丁」容易被误读成「还在被支持」。判断排期时，把只留安全支持视为已经到期更实用。
排期该按哪个日期倒推
以活跃支持到期日作为触发点，往前留出准备期：先用测试环境验证程序与扩展在新版本上的表现，再排维护窗口，最后才是正式切换。运行环境版本与程序版本要一起排，两者到期日常常不同步，分开处理会让某一条线长期停在旧分支上。
自建系统的部署方式决定了回退手段。用 Docker 镜像部署的，回退只需切回上一个镜像标签，前提是历史标签还留着；用宝塔面板或 aaPanel 一键部署的，回退依赖面板备份与站点目录快照；用 LNMP 手工部署的，回退靠你自己那份配置与数据库备份。默认监听端口与反代规则也要在切换后复核一次，避免升级完成却从外网访问不到。
升级前的备份与回归准备
备份要覆盖数据与静态文件，两样缺一都算没备完。上传的附件、生成的缩略图与主题模板都属于静态文件面，只备数据库的站点在恢复时最常发现这一块是空的。备份做完要真的恢复一次到隔离环境里看能不能起来，只生成文件不验证的做法，风险等到出事那天才暴露。
回归清单按链路写：后台登录与验证码、文章创建与发布、栏目与列表页、图片上传、表单提交、接口读取。每项记下升级前的表现，升级后逐条比对，出现差异先判断是版本行为变化还是配置遗漏。
上线后的核对项
切换完成后至少核对三件事：程序报告的运行环境版本确实是新档；错误日志在一个业务周期内没有新增兼容性告警；回退路径可用，镜像标签或备份文件仍能被找到。把这三条写进变更记录，下一次排期就有可参考的时间成本。
常见问题
只留安全支持的版本还在发安全补丁，为什么急着升？ 因为功能缺陷与依赖适配不再修。安全补丁只解决被披露的问题，不能替你处理扩展行为变化与兼容断裂。
能不能只升运行环境不升程序？ 可以，但要看程序的版本支持范围。程序对旧档的兼容同样会终止，两条线要一起确认。
排期需要提前多久开始准备？ 以能否在到期日前完成一次完整恢复演练为准。测试环境验证、维护窗口申请、备份验收三段都要占时间。
没有备份怎么办？ 先补一次覆盖数据与静态文件的备份并验证恢复，再做任何升级。升级导致无法回退的损失，通常比延期升级更大。