PHP 8 不是一个单一版本，而是一条从 8.0 延续到 8.5 的语言与运行时演进线。本文先把版本数量、支持状态、升级目标和验证方法放在同一张地图中，帮助你避免“只看新特性、忽略维护窗口”的选择错误。
先看结论：PHP 8.0–8.5 共 168 个稳定版本。8.0、8.1 已结束支持；8.2–8.5 仍在官方支持表中。PHP 8.6 目前仅有 Alpha 1–3 与 Beta 1，不可用于生产环境。
一张表看清 PHP 8 版本线
| 分支 | 稳定版本数 | 官方维护状态 | 部署建议 |
|---|---|---|---|
| PHP 8.0 | 30 | 已 EOL | 仅维护遗留环境；应制定迁移计划 |
| PHP 8.1 | 35 | 已 EOL | 不宜继续作为新项目目标版本 |
| PHP 8.2 | 34 | 安全支持至 2026-12-31 | 已有兼容性基础时的过渡选择 |
| PHP 8.3 | 34 | 安全支持至 2027-12-31 | 成熟项目的稳妥升级目标 |
| PHP 8.4 | 25 | 安全支持至 2028-12-31 | 需要评估属性钩子、扩展与 DOM 变化 |
| PHP 8.5 | 10 | 安全支持至 2029-12-31 | 新项目可评估；先验证依赖生态 |
| PHP 8.6 | 0 稳定版 / 4 预发布 | 不可用于生产 | 仅隔离测试与问题反馈 |
官方的维护规则是：一个分支首次稳定发布后通常有两年完整支持，随后两年只修复关键安全问题，四年后进入 EOL。因而“能安装”不等于“仍被支持”；生产环境的版本选择应先排除 EOL 分支，再把框架、扩展与宿主系统的兼容性一起考虑。PHP 官方支持版本政策 是判断维护窗口的基准来源。
从语言能力看演进方向
| 阶段 | 代表能力 | 工程意义 | 常见误区 |
|---|---|---|---|
| 8.0 | 类型系统、Attributes、match、Nullsafe | 把大量约定转为运行时可验证的语法 | 把 JIT 当作所有 Web 项目的固定加速器 |
| 8.1 | Enums、readonly、Fibers | 强化领域建模与异步库底层能力 | 认为 Fiber 自动产生多线程并发 |
| 8.2 | readonly class、Random、动态属性弃用 | 减少对象模型隐患 | 继续无提示地给任意对象挂字段 |
| 8.3–8.5 | Override、属性钩子、URI、管道 | 增强重构安全性与 API 表达力 | 跳过依赖和扩展验证直接升级 |
选择目标版本的可执行框架
若你维护的是一个旧项目，应先在当前版本上补齐测试，随后选择仍在支持期内、且框架官方已声明兼容的分支。若是新项目，则可将更长的安全维护窗口作为重要因素，但不能省略 Composer 依赖、PECL 扩展、镜像和系统包的验证。
bash
# 在目标主机或容器中记录当前运行时与配置来源
php -v
php --ini
php -m | sort
composer check-platform-reqs这组命令不会替你完成升级，但能把“当前 PHP 版本、加载的 ini、启用扩展、依赖平台要求”固化为可比对的基线。升级前后都执行一次，并将差异纳入变更记录。
php
<?php
// 运行时版本门禁示例：部署前检查最低 PHP 要求
if (PHP_VERSION_ID < 80300) {
throw new RuntimeException('该服务要求 PHP 8.3 或更高版本');
}
echo PHP_VERSION, PHP_EOL;将版本约束写进启动检查可以避免镜像、CLI 与 FPM 使用了不同 PHP 二进制时悄然上线。对共享服务器尤其重要。
升级与回滚的最小闭环
- 备份当前制品、锁定依赖和 PHP-FPM 配置；
- 在预发布环境使用目标小版本执行单元、集成和关键链路测试；
- 灰度切换并监控错误率、延迟、FPM 进程和日志；
- 保留上一套可启动运行时与依赖锁文件，异常时以发布单元回滚。
结语
PHP 版本升级不是把二进制文件替换掉就结束了。更可靠的路径是先确认支持状态与升级边界，再让依赖、测试、部署和回滚共同构成闭环。本文的版本结论以 PHP 官方资料为准；在实际变更前，仍应在与生产尽量接近的环境中完成验证。