PHP 停止维护时间表（2026）：哪些 PHP 版本仍受支持

当 PHP 官方不再为某个版本发布安全修复时，这个版本就到了停止维护（EOL，End of Life）。网站照样能跑，这也正是很多服务器在旧版本上一待就是好几年的原因。但下一个严重漏洞不会再有人帮你修。2026 年 10 月就是个例子：PHP2Shell 远程代码执行漏洞在 8.2 到 8.5 中都修复了，而 8.1 及更早的版本没有任何官方修复。

PHP 各版本支持期限

从 PHP 8.1 起，每个分支有两年的活跃支持和两年的仅安全修复支持，都在 12 月 31 日结束。

官方来源是 php.net/supported-versions。本表日期核对于 2026 年 10 月 21 日。

停止维护在实际中意味着什么

• 没有安全补丁。 出现 PHP2Shell 这样的漏洞时，受支持的分支当天就有新版本，停止维护的分支什么都没有。
• 框架也会抛弃你。 Laravel、Symfony 和 WordPress 插件的新版本会放弃旧 PHP，你也就只能停在旧的、未修补的应用代码上。
• 主机商可能会逼你升级。 共享主机和面板经常移除停止维护的 PHP，或者对「延长支持」额外收费。
• 「延长支持」是一种商业产品，不是补丁政策。 发行版或商业回移服务可以付费帮你继续修补某个分支。作为过渡没问题，但要确认它具体覆盖了哪些 CVE。

我的网站用的是停止维护的 PHP 吗？

在服务器上，php -v 显示的是命令行版本；Web 服务器的版本要在主机面板或 FPM 程序里单独确认。从外部看，很多服务器会在响应头里暴露版本：

curl -sI https://example.com | grep -i x-powered-by

网站漏洞扫描器会把这个响应头和上表对照，自动标记停止维护的版本和受 PHP2Shell 影响的版本。

最省事的升级顺序

1. 先升到受支持的分支，再升到最新。 从 7.4 升到 8.3 的工作量通常比想象中小，大部分问题来自被移除的函数和更严格的类型处理，静态分析能在用户发现之前把它们找出来。
2. 针对目标版本跑测试和静态分析（PHPStan 或 Psalm），再用 PHP_CodeSniffer 的 PHPCompatibility 规则列出废弃的调用。
3. 用 Composer 更新依赖：先在旧版本上尽量更新，切换 PHP 后再更新一次。
4. 先升级预发布环境，把结账、登录、表单都点一遍，看错误日志。
5. 再切生产环境并重启 PHP-FPM。保留旧的 PHP 软件包，方便快速回滚。

如果你在用 PHP 8.2，现在就规划迁移到 8.4：安全支持在 2026 年 12 月 31 日结束，之后的严重修复不会再覆盖你。

升级之后

设置 expose_php = Off，让版本号不再出现在响应头里，然后重新扫描网站。老代码升级需要帮手？集中修复服务包含升级方案，托管运维会让服务器之后一直保持在受支持的版本上。