PHP 终止维护究竟指的是什么？
所谓 PHP 终止维护（End of Life），是指该版本已不会再收到官方推出的安全更新。 到 2026 年 11 月，7.4、8.0 与 8.1 皆已结束，8.2 也将于 2026 年 12 月 31 日截止。网站若仍停在这些版本，往后被发现的安全问题就不会再有官方补丁。
PHP 可比作大楼的承重骨架，页面与功能都建在其上。维护结束类似营造厂表示不再派员检查或修缮：建物仍可入住，但之后的结构瑕疵必须自己想办法。
与业主沟通时，经常出现「网站沒故障，为何要升级？」的疑问。多数时候听起来合理，直到漏洞真正曝光的那一天。
从 2026 年 10 月的 PHP2Shell 能学到什么
2026 年 10 月 21 日，PHP 官方紧急处理两个合称 PHP2Shell 的漏洞（CVE-2026-109618、CVE-2026-109619），严重分数均为 CVSS 9.2。缺陷位于解析连线请求的阶段，网站程式尚未执行就可能遭到利用。对方不必取得帐号，站内既有的登入与表单验证也起不了阻挡作用。
这次事件有三点适合企业记住：
- 正式修补只发给 8.2 及以上：包含 8.2.35、8.3.36、8.4.27、8.5.12。7.4、8.0、8.1 仅有原始码层级修正，还须等待主机商或作业系统厂商重新封装，有些反应迟缓，有些则完全不处理。
- 入侵尝试早于公开说明：国外云端服务在公告前 4 天已看到攻击行为，公告后数日内自动化扫描迅速增加。扫描对象涵盖整个网路，不会挑公司大小。
- 主机商更换 PHP，不等于网站已脱险：许多网站留在旧版，是因为程式一换新版就会出错，主机商因此不愿更动。
直接说，终止维护的风险平时不易看见，要等下一个像 PHP2Shell 这样的漏洞，损失才会集中出现。
目前各版本还能维护多久
现行 PHP 版本通常先有约两年的一般维护，同时修错误与安全问题，其后再约两年只处理安全更新，合计大约四年。下表是各版本目前的情形：
| 版本 | 安全支援截止日 | 2026 年 11 月现况 | 建议方向 |
|---|---|---|---|
| 7.4 | 2022-11-28 | ✗ 终止已满四年 | 应尽快升级，通常要连框架一起处理 |
| 8.0 | 2023-11-26 | ✗ 维护已结束 | 宜尽早安排升级 |
| 8.1 | 2025-12-31 | ✗ 维护已结束 | 建议尽速升版 |
| 8.2 | 2026-12-31 | ! 剩余不到两个月 | 年底前排入时程 |
| 8.3 | 2027-12-31 | ✓ 只剩安全更新 | 尚可使用，明年再规划 |
| 8.4 | 2028-12-31 | ✓ 仍在维护期 | 新专案与升级的优先版本 |
| 8.5 | 2029-12-31 | ✓ 仍在维护期 | 新专案与升级的优先版本 |
较稳妥的做法是一次升到 8.4 或 8.5。若只停在 8.3，明年底多半还要再测一轮，等于同一套验证付两次钱。
如何查出网站实际的 PHP 版本
现场常见的状况是，负责人並不知道网站跑哪一版，当初的厂商也已经联络不到。确认方式大致有三种：
- 向维护厂商或主机商询问：请对方提供网站「真正在执行」的 PHP 版本。同一台主机可能同时安装数个版本，控制台看到的不一定是网站正在用的。
- 进入主机管理后台：cPanel、Plesk 这类介面多半有「PHP 版本」或「PHP 设定」页面。
- 查看回应标头：有些网站会在回应里带出版本号，但多数主机为了安全会隐藏，查不到属于正常情况。
一并确认网站使用的内容管理系统或程式框架，以及该框架自身的版本。框架也有独立的维护期限，旧框架常常无法搭配新版 PHP，所以两者往往要一起升级。
维持旧版、购买延长维护，或升级到新版
一旦确认网站使用的是已终止维护的版本，实际上可以走三条路：
| 对照项目 | 继续沿用旧版 | 付费延长安全维护 | 升到 8.4 或更新 |
|---|---|---|---|
| 能否收到安全修补 | ✗ 收不到 | ! 取决于厂商，常常延后 | ✓ 有官方正式修补 |
| 短期支出 | ✓ 当下不用付钱 | ! 每年都要付费 | ! 一次付清的升级费用 |
| 长期支出 | ✗ 出事后的復原成本难以估计 | ✗ 年年付费，问题依旧 | ✓ 之后只需例行的小版本更新 |
| 新外挂与新功能是否可用 | ✗ 愈来愈多新套件不支援旧版 | ✗ 同样无法使用 | ✓ 可以使用 |
| 主机商是否继续提供该版本 | ✗ 不少主机商会强制撤下旧版 | ! 要先确认主机商是否配合 | ✓ 会继续提供 |
| 适合什么情况 | 网站即将下线或准备整站改版 | 三到六个月内要改版，需要过渡 | 网站还要再使用两年以上 |
判断可以很直接：网站若还要再用两年以上，就安排升级；若半年内要整站改版，就把预算留给改版，过渡期间请主机商先套上暂时的防护。最不建议「先搁着，等出事再谈」。网站被入侵后的清除与復原，花费和停机时间通常都比升级更高。
动手升级时，哪些环节必须一起改
不少人以为升级 PHP 只是主机商按一个按钮。按钮确实有，但旧网站按下之后，常见结果是白画面、后台无法登入，或结帐时发生错误。原因是下面几个部分要一起调整：
- 网站程式本身：新版 PHP 移除了部分旧语法，写得越早的网站要改的地方越多。从 7.4 跨到 8.4 经过好几个版本，工作量与从 8.2 升到 8.4 相差很大。
- 外挂与套件：网站使用的外挂和程式套件都要换成支援新版的版本，已经停更的外挂则需寻找替代。
- 金流与电子发票串接：金流与电子发票厂商的套件通常要一并更新，而且要在测试环境实际完成一笔付款、开立一张发票，确认付款状态与通知信都正常。
- 资料库写法：少数旧式查询在新的资料库连线方式下会失败。
工期视网站规模而定。有会员、购物车、金流或多语系的网站，要验证的项目较多，时间也较长。仍使用 8.2 的网站，建议现在就请厂商评估时程，才有机会在年底前完成。
施工前后建议逐项确认的问题
委託厂商升级时，可以直接用下表提问。回答具体，代表对方做过规划；回答含煳，代表风险仍留在自己这边：
| 要提出的问题 | 值得放心的回答 | 需要留意的回答 |
|---|---|---|
| 施工前会不会备份？ | 程式与资料库都会完整备份，出问题可以还原 | 「主机商应该有备份」 |
| 升级在哪里进行？ | 先在测试站做完，验收通过才切换正式站 | 「直接在正式站修改，比较快」 |
| 会验证哪些功能？ | 依网站实际功能列出清单，包含表单、会员、购物车与各种付款 | 「首页打得开就可以」 |
| 金流要如何确认？ | 每种付款方式各下一笔测试订单，核对付款状态与通知信 | 完全沒有提到金流 |
| 升级后若出问题怎么处理？ | 有明确的保固期间与回覆时限 | 「以后再商量」 |
| 框架和外挂会不会一起升？ | 会，並说明哪些外挂需要替换 | 「只更换 PHP 版本」 |
升级完成后的第一週，要特別看错误纪录、表单通知信是否正常寄出，以及订单与付款状态。建议把 PHP 版本纳入每年的网站维护项目，在支援截止前一年就排好下一次升级，不要每次都等漏洞公告才动作。维护预算可以依客制网站每年需要照顾的范围来估算。
结语：別等到下一个漏洞才处理升级
很少人觉得 PHP 升级有趣，但它是网站资安里少数做了就会降低风险的工作。可以记住下面三点：
- 先查版本，再决定要不要支出：只有知道网站与主机实际使用的 PHP 和框架版本，才判断得出风险。
- 还要再用两年以上就升级，而且直接升到 8.4 以上：避免明年把同一套测试再做一次。
- 升级必须先在测试站完成：先备份、逐项验收，再切换上线，正式网站在施工期间仍可正常营运。
若还不清楚网站现况，可先依资安防护要点做一次盘点，或请目前的维护人员协助查看版本，以及需要调整的范围。
