网站依赖的PHP大版本还在安全维护期里吗，三步自查怎么做

确认 PHP 大版本还在不在安全维护期，看的是官方支持表里的两个截止日：主动支持截止日与仅安全支持截止日。前者到期意味着普通缺陷不再修，后者到期意味着连严重安全问题都不再出补丁。自查只需三步：查清线上实际运行的大版本、对照支持表定位它落在哪一档、把两个截止日写进维护台账并设定处理时限。

三档支持分别给什么修复

官方支持表把每个分支分成三档：主动支持阶段会修复上报的缺陷与安全问题并按节奏发布小版本；仅安全支持阶段只处理严重安全问题，发布按需进行；停止维护之后不再有任何补丁，官方明确建议尽快升级。

以 2026-10-09 的支持表为例，PHP 8.2 的主动支持已在 2024-12-31 结束，仅安全支持到 2026-12-31；8.3 的仅安全支持到 2027-12-31；8.4 的主动支持到 2026-12-31、安全支持到 2028-12-31；8.5 的主动支持到 2027-12-31、安全支持到 2029-12-31。

分布数据说明了什么

W3Techs 在 2026-10-09 的统计显示，在使用 PHP 的网站里，版本 8 占 64.6%，版本 7 占 27.5%，版本 5 占 7.8%，仍有 0.1% 的网站停留在版本 4。这组数字的实际含义不是「新版本占比高就够了」，而是长尾真实存在：版本 7 与更早分支合起来仍然是一个庞大的存量，而这些分支大多已经或即将只剩安全支持甚至停止支持。

环境升级通常滞后于程序升级，原因很具体：换大版本要同时验证扩展、模板引擎和依赖库，改一处就牵动整站。很多站点的程序本身是新的，运行环境是旧的，公告里的修复到了这台机器上就断在半路。

三步自查

第一步，查实际运行版本。不要看部署脚本里写的版本，要看运行时上报的版本：一个服务器上同时存在多个 PHP 版本的情况很常见，站点目录与解析处理器未必对应同一个分支。

第二步，对照官方支持表定位档位，把主动支持截止日与仅安全支持截止日两项抄进台账，同时记下这个站点由谁负责升级、需要验证哪些扩展。

第三步，检查与运行环境绑定的东西。面板一键部署或容器化部署都会把版本选择固化在配置里：宝塔面板与 aaPanel 的站点设置、镜像里内置的运行时、反向代理的转发规则，这几处的版本口径要对齐。若运行在容器里，基础镜像升级与程序升级要当作同一次变更安排。

不升版本的真实代价

短期内看不出差别，风险集中在三个地方。一是漏洞暴露窗口：仅安全支持阶段本来就只处理严重问题，响应速度低于主动支持；进入停止维护后连这一层也没了。二是依赖连带：运行环境不升级，上层组件的新版本会逐步抬高最低要求，最后被迫一次做多项大变更。三是恢复能力：扩展缺失、编译环境不一致会让回滚路径变窄，出问题时连降级都不顺畅。

值得一提的是另一种形态的对比。AnQiCMS 这类以 GoLang 加 Iris 框架与 GORM 组成的技术栈，运行时随程序一起构建交付，不存在「站点运行时版本滞后于程序」这同一类问题；环境责任从常驻解释器转移到了构建与部署环节，宝塔面板或 Docker 镜像两种部署方式下要核对的对象也因此不同。这不是谁替代谁，而是自查清单要按栈的形态重写一遍。

常见问题

只修安全问题的分支能不能继续放着？ 可以短期维持，但要接受两点：严重问题的判定权在官方，普通缺陷不再修，以及下一次安全公告的处理时限要按天算而不是按周算。

怎么知道自己站点用了哪个处理器？ 从站点配置反查解析规则，再看该规则指向的处理器进程，两处一致才算确认。

升级大版本要做哪些验证？ 扩展可用性、数据库连接、时间与时区处理、以及与程序版本兼容的下限，四项依次验证并保留回滚点。