PHP 7.4已完全EOL，不修复CVE-2026-109618/109619等任何漏洞，继续使用即暴露高危攻击面；须立即升级至8.2+受支持版本，并通过静态分析、运行时测试及组件兼容性核查确保平滑迁移。

先看官方支持状态

PHP 7.4 已于 2022 年 11 月 28 日结束安全支持，当前（2026 年 10 月）属于完全 EOL 状态。这意味着它不再接收任何漏洞修复，包括近期披露的两个 CVSS 9.2 分远程代码执行漏洞（CVE-2026-109618 / CVE-2026-109619）。只要项目对外提供 Web 服务，继续使用 PHP 7.4 就等于主动暴露高危攻击面。

用工具扫描兼容性问题

静态分析是判断升级可行性的第一步，不运行代码就能发现大部分语法和语义冲突：

• 运行 phpstan/phpstan：安装后执行 vendor/bin/phpstan analyse --level=max src/，重点关注 Dynamic property access、Deprecated function、Union type mismatch 类报错
• 检查废弃函数：如 create_function()、each()、mysql_* 系列函数在 PHP 8.2 中已彻底移除，搜索项目全量代码确认是否残留
• 验证扩展依赖：运行 php -m 列出已启用模块，对照 PHP 8.2 兼容列表（例如 igbinary 3.2.14 不支持，redis 5.3.6 尚未正式支持）

跑一遍最小化运行时测试

工具扫描只能覆盖静态层面，真实行为需靠轻量级执行验证：

PHP 8.5.12

修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。

下载

• 用 php -l 批量检查所有 PHP 文件语法： find . -name "*.php" -exec php -l {} \; 2>&1 | grep "Fatal error\|Warning"
• 临时在入口文件（如 index.php 或 wp-load.php）顶部加一行：echo "PHP Version: " . PHP_VERSION . " (SAPI: " . php_sapi_name() . ")"; die;，确认 Web 请求实际加载的是 PHP 8.2 而非 CLI 版本
• 对关键业务路径做“冒烟测试”：比如用户登录、订单提交、后台配置保存等核心流程，观察是否出现 Fatal error: Uncaught TypeError 或 Notice: Undefined array key 类错误

查框架与插件的明确支持声明

第三方组件往往比你自己写的代码更早成为升级瓶颈：

立即学习“PHP免费学习笔记（深入）”；

• Laravel：8.x 起支持 PHP 8.0+，但 Laravel 6/7 需手动升级到 8.x 才能兼容 PHP 8.2
• Symfony：6.4+ 官方支持 PHP 8.2，5.4 及更早版本不支持
• WordPress：6.0+ 支持 PHP 8.2，但必须确保所有激活插件标注了 Requires PHP: 8.2 或通过 Plugin Compatibility Checker 插件实测通过
• 查看 composer.json 中 "php": "^7.4" 是否已更新为 "^8.2"，否则 composer install 会拒绝安装新版依赖