php 8.2的官方上游安全支持，到2026年12月31日就正式到期了。这次操作要分两步走：先安装包含php2shell漏洞修复的安全补丁，再为后续迁移到新分支安排兼容性验证，两项任务要分开验收，不能混为一谈。
补丁更新与分支迁移，对应两个不同时间维度的需求
现在要打的安全补丁，是用来修复已经公开披露的已知漏洞，而跨版本分支迁移，是为了后续能持续拿到官方的安全更新。要是把两件事揉成一次大改，很容易在等兼容性测试的空窗期，一直没打上眼下急缺的安全补丁；要是只装当前补丁完全不管迁移，又很容易转头就忘了2026年底PHP 8.2就停更的截止时间。
PHP官方公开的支持周期表，明确标注了8.2分支的安全支持截止日期。这里说的都是上游官方的支持规则，如果你用的是Linux发行版打包的PHP、或者商业服务商提供的PHP环境，对方可能有单独的延长维护政策，一定要自己核对对应的服务合同、软件仓库公告、官方通知，不能默认所有安装来源都统一遵守这个截止时间。
立即学习“PHP免费学习笔记（深入）”；
先补完当前环境的漏洞，再安排可回滚的新分支迁移
这次PHP 8.2分支的首个带该漏洞修复的正式安全版本是8.2.35。如果你是直接用官方上游发布的源码包部署的环境，至少要升级到这个版本号；如果是用发行版自带的回补补丁包，也要核对对应的完整包号确认修复到位。补丁装完之后一定要重启对应的PHP服务进程生效，这一步操作和你之后准备升级到哪个新分支完全没关系，先做完再说。
这类内存安全漏洞的修复，改动了解释器内部的异常退出逻辑和状态清理流程，光靠改应用层代码根本补不上。而跨大版本分支升级，还可能影响PHP的语言行为、废弃配置项、扩展的兼容性，所以必须单独做一套测试、灰度切换、回退的方案。两类改动都很重要，但验收的标准完全不一样。
| 候选分支 | 上游安全支持至 | 选择时重点考虑 |
|---|---|---|
| 8.2 | 2026-12-31 | 当前修补与短期过渡 |
| 8.3 | 2027-12-31 | 应用兼容与后续迁移成本 |
| 8.4 | 2028-12-31 | 扩展和框架支持情况 |
| 8.5 | 2029-12-31 | 新分支验证与依赖成熟度 |
把迁移计划拆成四个可落地的阶段
清点：把所有站点、接口、消费队列、定时任务在用的PHP版本全列出来，同步记录每个项目用到的框架、第三方扩展、商业组件、对应维护人，共享主机上跑的每个站点，也要各自检查自己绑定的PHP版本。
验证：选好符合要求、还在官方支持周期内的目标分支，搭一套和生产环境配置完全一致的隔离测试副本，对照跨版本的官方迁移指南逐条检查变更点，把登录、支付、文件上传、数据导出、后台定时任务这些核心业务路径全跑一遍真实流程。
切换：提前定好维护窗口、数据写入的边界规则、流量切分方案。多节点集群先做灰度放量，单节点环境先反复核验备份和灾难恢复步骤，别只准备好升级用的二进制包，却忘了做数据恢复的预案。
维护：把各个PHP版本的支持截止日期录入到资产台账里，纳入日常的例行更新流程。每次新增服务器、或者从备份恢复环境的时候，都顺手检查一遍PHP版本，避免旧的不受支持的环境偷偷重新上线。
用日期计算脚本为计划提供明确的时间基准
<?php
// 固定核验日期，便于复现文章的日期差；不是供应商延长支持查询。
$checked = new DateTimeImmutable('2026-10-22',new DateTimeZone('UTC'));
$end = new DateTimeImmutable('2026-12-31',new DateTimeZone('UTC'));
echo json_encode(['branch'=>'8.2', 'checked_on'=>$checked->format('Y-m-d'),
'upstream_security_end'=>$end->format('Y-m-d'),
'calendar_date_difference_days'=>(int)$checked->diff($end)->format('%r%a'),
'action'=>'apply current patch, then plan a supported branch migration'],
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
把这段代码存为support-window.php直接运行即可。示例里固定用2026年10月22日作为核验基准日，方便大家复现计算结果，我这边是在本地PHP 8.5.10的WebAssembly环境里跑的，输出结果看下面的截图。实际排期的时候，还要把业务冻结期、服务商的例行维护时间都纳入考量。
老业务与新业务，目标选择可以不同
跑了很多年的老业务，优先确认你在用的扩展、框架、商业组件都能在目标环境稳定运行，必要的时候可以先选兼容性更好的过渡分支，同时写清楚下一次迁移的时间窗口，不能因为某个旧插件还没做完验证，就无限期停在老版本不升级。
新上线的业务，可以直接选剩余维护周期更长的分支，但也不能光看版本号高就乱选，得跟着你实际用的依赖的支持情况走。版本数字新不是唯一判断标准，部署自动化程度、测试用例覆盖度、可观测性配置、故障恢复方案，共同决定升级过程能不能稳不出问题。
迁移容易踩到的四个坑
- 把安全支持误认成功能支持：处于仅安全维护阶段的分支不会继续获得普通功能改进。
- 只测试首页就上线：登录、上传、队列和计划任务可能使用不同扩展与配置，很容易出问题。
- 回退恢复了旧漏洞：提前准备好打了补丁的兼容恢复方案，必要时保持旧环境入口隔离。
- 依赖过期无人负责：给每个阻塞迁移的待验证项指定负责人和明确复查日期。
当前安全补丁全部验证通过后，把补丁验证证据和迁移计划分别归档。前者证明这次的已知漏洞已经处理完毕，后者保证在PHP 8.2的官方支持到期之前，你手里有已经验证好的可用替代环境。
