截至2026年4月，PHP 8.2已结束安全支持（截止2025-11-28），不再接收任何补丁；PHP 8.3是当前唯一处于活跃支持期的版本，新项目应直接选用。
PHP 8.2 是否还在官方支持期内
截至 2026 年 4 月，PHP 8.2 已**结束活跃支持**，进入**安全支持期尾声**。根据 PHP 官方生命周期政策，8.2 的安全支持截止日期是 2025-11-28（即发布后 3 年整）。当前已过期约 5 个月，不再接收任何安全补丁或修复。
这意味着：哪怕你今天全新启动项目，选 PHP 8.2 就等于默认接受已知 CVE 不会被修复的风险。这不是“还能跑”，而是“官方已放手”。
- PHP 8.3 是当前唯一处于 活跃支持期 的版本（截至 2026 年 4 月）
- PHP 8.4 尚未发布（预计 2026 年 11 月）
- PHP 8.1 及更早版本均已 EOL（终止支持）
为什么还有人坚持用 PHP 8.2？常见误判点
不少团队仍把 PHP 8.2 当作“最新稳妥选择”，根源在于混淆了三个概念：功能可用性、框架兼容性、官方支持状态。
例如：
立即学习“PHP免费学习笔记（深入）”；
- ThinkPHP 6.1.2 标明“兼容 PHP 8.2”——这仅表示“不报错”，不等于“推荐使用”或“仍在维护”
- WordPress 官方文档仍写“推荐 PHP 7.4+”，是因为它要兜底老旧主机，不是对新项目的建议
- 某些云服务商控制台默认 PHP 版本仍是 8.2，属于滞后配置，不能当作决策依据
真正影响上线的，从来不是“能不能跑”，而是“出问题时有没有人兜底”。一旦线上遭遇 unserialize() 相关 RCE 或 JIT 编译器级漏洞，PHP 8.2 就没有补丁可打。
PHP 8.2 vs 8.3：升级成本真有那么高？
从 8.2 升到 8.3 的实际迁移门槛，比多数人预想的低。官方将绝大多数变更归类为“向后兼容”，且明确标注了少数必须处理的破坏性改动。
重点关注以下几处：
-
json_validate()替代json_decode($x, null, 512, JSON_THROW_ON_ERROR)—— 更轻量、无异常开销 -
#[\Override]属性能提前暴露方法名拼写错误，不是语法强制，但加了就少 debug 一小时 - 动态类常量访问语法
Config::{$const}在 8.2 中会报ParseError，8.3 原生支持 - 部分扩展（如
sqlsrv）需确认是否已发布 8.3 兼容版，但主流如pdo_mysql、openssl无感升级
实测中，90% 的 Laravel/ThinkPHP 项目在 CI 中开启 php83 环境后，仅需改 1–2 处类型声明或关闭 dynamic_properties 报错即可通过。
新项目起步，直接跳过 8.2 的理由
如果你正在初始化一个新项目，选 PHP 8.2 唯一合理的场景是：你明确知道未来 12 个月内不会更新运行环境，且服务器 OS（如某 CentOS 衍生版）连 8.3 的包都编译不过。
除此之外，所有其他情况都该选 8.3：
-
random_bytes()和Random\Randomizer在 8.3 中统一了行为，避免旧项目里魔改/dev/urandom路径的 hack - JIT 编译器在 8.3 中进一步减少内存抖动，对 CLI 长任务（如队列消费）更友好
- 所有新发布的 Composer 包（如
monolog/monolog ^3.7）已默认要求 PHP 8.2+，而 8.3 兼容性更宽松 - 最现实的一点：2026 年起，主流 PaaS（如 Laravel Forge、Cloudways）的新建实例已默认 PHP 8.3
版本选型不是技术怀旧，而是风险预算。PHP 8.2 的“稳定”是过去时，它的兼容性红利早已被 8.3 吸收，而安全负债却在持续累积。新项目从第一天起，就该站在支持线的内侧，而不是边缘试探。
