这是一篇针对 PHP 8.2 分支的维护版本索引与阅读方法文章。它完整覆盖从 8.2.0 到 8.2.33 的 34 个官方稳定标签，并说明怎样把“某个小版本存在”与“某个小版本适合立即部署”分开判断。
阅读原则：小版本通常承载 bug 修复与安全修复。实际变更内容必须以 PHP 官方 ChangeLog 和对应的官方发行公告为准，不能仅凭版本号推断影响范围。
PHP 8.2 稳定小版本完整清单
| 分组 | 官方稳定版本 | 阅读与验证方式 |
|---|---|---|
| 第 1 组 | 8.2.0、8.2.1、8.2.2、8.2.3、8.2.4、8.2.5、8.2.6、8.2.7 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 2 组 | 8.2.8、8.2.9、8.2.10、8.2.11、8.2.12、8.2.13、8.2.14、8.2.15 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 3 组 | 8.2.16、8.2.17、8.2.18、8.2.19、8.2.20、8.2.21、8.2.22、8.2.23 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 4 组 | 8.2.24、8.2.25、8.2.26、8.2.27、8.2.28、8.2.29、8.2.30、8.2.31 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 5 组 | 8.2.32、8.2.33 | 以官方 ChangeLog 对应条目核查修复内容 |
以上清单来自 PHP 官方仓库标签的交叉核验。它用于防止在运维文档、镜像标签或升级单中漏写、错写、或把预发布版本误当成稳定版。尤其在多台主机并存时，建议同时记录 CLI、FPM 和队列进程各自实际加载的版本。
如何阅读 ChangeLog，而不是只看“修复了什么”
| 阅读位置 | 应回答的问题 | 行动 |
|---|---|---|
| Core / Opcache | 是否影响语言执行、JIT、内存或预加载 | 建立回归用例，关注异常和峰值内存 |
| 扩展条目 | 是否启用该扩展，是否处理不可信输入 | 对启用扩展、接口和文件格式做专项测试 |
| 安全公告 | 受影响版本和修复范围是什么 | 安排最短可行的维护窗口，并保留回滚制品 |
| 构建与平台 | 系统库、Windows 或特定 SAPI 是否受影响 | 在同类操作系统、容器基础镜像上验证 |
部署前后核对清单
bash
# 部署前：记录基线与目标版本
php -v
php -m | sort > /tmp/php-8.2-modules.before
php --ini
# 部署后：确认 CLI 与服务进程使用的是预期运行时
php -r 'echo PHP_VERSION, PHP_EOL;'
systemctl status php*-fpm --no-pager命令中的通配服务名仅为提示；不同发行版的 PHP-FPM unit 名称不同。应先用 systemctl list-units 或你的编排平台确认实际服务名。关键在于把“包已安装”改成“进程正在使用该版本”的证据。
php
<?php
// 可以纳入健康检查的版本输出；不要把详细 phpinfo 暴露到公网。
header('Content-Type: application/json');
echo json_encode([
'php_version' => PHP_VERSION,
'sapi' => PHP_SAPI,
'timestamp' => gmdate('c'),
], JSON_THROW_ON_ERROR);何时应该立即升级，何时应先验证
官方公告标明为安全发布时，应根据暴露面、受影响扩展和变更窗口提高优先级；但“高优先级”并不代表跳过预发布验证。对于复杂框架项目，至少应先跑依赖安装、迁移、关键业务回归和后台任务，再以灰度方式切换。若生产版本已不受支持，更新到该分支的最后一个小版本只能降低已知风险，不能替代迁移到仍受支持分支。
结语
PHP 版本升级不是把二进制文件替换掉就结束了。更可靠的路径是先确认支持状态与升级边界，再让依赖、测试、部署和回滚共同构成闭环。本文的版本结论以 PHP 官方资料为准；在实际变更前，仍应在与生产尽量接近的环境中完成验证。