VPS知识分享站先说结论：PHP 8.2 会在 2026 年 12 月 31 日停止支持，之后不再有官方安全更新。10 月 21 日发布的 8.2.35 是这一分支最后的安全版本之一，修的是 PHP2Shell 那两个 CVSS 9.2 的核心层 RCE。还在跑 8.2 的站点，现在就该排升级，别等到 12 月最后一周末。
升级前先确认三件事：
- 目标版本：保守选 8.3，想多撑几年选 8.4 或 8.5
- 依赖兼容：框架、CMS、插件、扩展、加密组件都要过一遍
- 回滚方案：快照、旧版本保留、FPM 切换开关
下面按“现状 → 盘点 → 选版本 → 兼容性检查 → 预发 → 上线 → 排错”讲，命令以 Debian/Ubuntu + PHP-FPM 为例。
PHP 8.2 现在是什么状态
PHP 8.2 在 2022 年底发布，按官方生命周期，2026 年 12 月 31 日结束安全支持。之后即使发现新的 RCE，官方也不会再为 8.2 发补丁。第三方发行版可能做 backport，但不能假设一定有。
这不是“12 月 31 日网站就会挂”，而是“从明年 1 月 1 日起，8.2 上的新漏洞没有官方修复”。PHP2Shell 已经证明核心层漏洞可以绕过应用代码直接打，继续停留在 EOL 版本，风险会随时间和扫描器一起增加。
先盘点再动手
php -v
php -m
php -i | grep -E 'Loaded Configuration|extension_dir'
composer show --direct 2>/dev/null | head -30
# 如果是 WordPress
wp core version --allow-root 2>/dev/null
# 如果是 Laravel
php artisan --version同时记录：哪些站点用哪个 PHP 版本、哪些跑在 Docker、哪些用面板、有没有 ionCube/SourceGuardian 加密、有没有老扩展（mysql、mcrypt、imagick、redis、igbinary）。这些信息决定升级难度。
选 8.3 还是 8.4/8.5
| 版本 | 适合 | 注意 |
|---|---|---|
| PHP 8.3 | 兼容性优先、老框架/老插件多 | 支持窗口比 8.4/8.5 短，但生态最稳 |
| PHP 8.4 | 主流 CMS/框架已适配 | 隐式 nullable 参数等有弃用警告 |
| PHP 8.5 | 新项目、想用最新特性 | 扩展和加密组件适配要逐个确认 |
不要跨太多版本一次跳。8.2 升 8.3 的破坏性最小，8.4/8.5 的新弃用更多。升级前先看官方 UPGRADING 文件和框架的兼容性说明，别只看“能启动”。
兼容性检查 Top 5
- 隐式 nullable 参数：
function f(Foo $x = null)在 8.4 起弃用，改成?Foo $x = null。老代码里很常见。 - 动态属性：8.2 起已弃用，8.3/8.4 继续报。给类加
#[AllowDynamicProperties]或补属性声明。 - 扩展：redis、imagick、gd、intl、bcmath 等要装对应新版本；用 PECL 编译的，确认支持新 PHP。
- 加密/编码组件：ionCube、SourceGuardian、Zend Guard 对新高版本的支持通常滞后，商业 PHP 程序尤其要先问厂商。
- 框架和 CMS：WordPress、Laravel、Drupal、ThinkPHP 等先升到支持 8.3/8.4 的版本，再升 PHP，顺序别反。
预发环境怎么搭
最稳的做法是克隆一台机器或容器，装目标 PHP 版本，跑同一套代码和数据库副本：
# 示例：Docker 起一个 8.4 环境做冒烟
docker run --rm -v /var/www/app:/app -w /app php:8.4-cli \
php -l index.php
# 有测试套件的跑测试
composer test
# WordPress 至少跑首页、登录、发布、上传、支付回调重点测五条链路：登录/会话、上传、支付回调、定时任务、邮件。再打开 error_reporting(E_ALL) 和日志，看看有没有弃用警告和 notice，别等生产才发现。
生产切换
- 打快照，保留旧 PHP 版本和旧 FPM pool 配置
- 安装新版本，先不切流量，用 CLI 和临时 pool 验证
- 切一个低流量站点或灰度实例，观察 24 小时
- 确认无误后切其余站点，保留旧 pool 至少一周
- 清理旧版本前，再跑一遍错误日志和慢日志
Nginx 的 fastcgi_pass 要指向新版本的 socket，例如 /run/php/php8.4-fpm.sock。切完 nginx -t 再 reload，别直接重启。
常见坑
- 面板装的 PHP 和系统 PHP 不是一套：宝塔、1Panel 有自己的 PHP 目录，改完要确认站点实际用的是哪个。
- opcache 没清：切版本后旧缓存可能还在，重启 FPM 并确认 opcache 状态。
- CLI 和 FPM 版本不一致：cron 跑的 PHP 可能是旧版本，
php -v和站点探针要分别看。 - 扩展缺失导致白屏：先看 PHP 错误日志，再看
php -m，别急着重装代码。 - 老代码用了已移除的函数：比如 mysql_*、ereg、each，这些在 PHP 7 就没了，升级前先静态扫描。
验证和监控
- 站点 200、登录、下单、支付回调、上传全部跑一遍
- PHP 错误日志里没有 fatal，弃用警告在可接受范围
- FPM 进程数、内存、响应时间与升级前对比
- cron、队列、邮件、第三方回调正常
- 监控 5xx 和 p95，观察一周
常见问题 FAQ
Q1：PHP 8.2 到 12 月 31 日就不能用了吗？
能用，但没有官方安全更新。公网服务不建议长期停留，尤其是电商、支付、后台这类高风险场景。
Q2：能直接从 8.2 升到 8.5 吗？
技术上可以，但跨度大、弃用多。建议先 8.2→8.3 验证，再考虑 8.4/8.5，或者在新机器上直接装目标版本做重建。
Q3：WordPress 能直接升吗？
先把 WordPress 核心、主题、插件升到支持新 PHP 的版本，再升 PHP。插件不兼容是白屏最常见的原因。
Q4：ionCube 加密的程序怎么办？
先问厂商有没有支持 8.3/8.4 的版本。没有就只能留在旧版本，或者换程序；这类组件通常比 PHP 本身更难搞。
Q5：升级后性能会变好吗？
通常有新版本优化，但别指望翻倍。先保证兼容和稳定，再谈性能；升级后用真实流量对比 p95 和错误率。
参考来源
总结
PHP 8.2 的 EOL 不是突发事件，但很容易被拖到最后。先盘点站点和依赖，选 8.3 或 8.4/8.5，在预发跑一遍真实链路，再灰度切换、保留回滚。升级本身不难，难的是把插件、扩展和加密组件这些边角提前查清楚。
需要一台干净机器做升级预发，可以按小时开一台萤光云香港 CN2 VPS，装目标版本跑通再动生产。
