这是一篇针对 PHP 8.1 分支的维护版本索引与阅读方法文章。它完整覆盖从 8.1.0 到 8.1.34 的 35 个官方稳定标签，并说明怎样把“某个小版本存在”与“某个小版本适合立即部署”分开判断。
阅读原则：小版本通常承载 bug 修复与安全修复。实际变更内容必须以 PHP 官方 ChangeLog 和对应的官方发行公告为准，不能仅凭版本号推断影响范围。
PHP 8.1 稳定小版本完整清单
| 分组 | 官方稳定版本 | 阅读与验证方式 |
|---|---|---|
| 第 1 组 | 8.1.0、8.1.1、8.1.2、8.1.3、8.1.4、8.1.5、8.1.6、8.1.7 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 2 组 | 8.1.8、8.1.9、8.1.10、8.1.11、8.1.12、8.1.13、8.1.14、8.1.15 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 3 组 | 8.1.16、8.1.17、8.1.18、8.1.19、8.1.20、8.1.21、8.1.22、8.1.23 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 4 组 | 8.1.24、8.1.25、8.1.26、8.1.27、8.1.28、8.1.29、8.1.30、8.1.31 | 以官方 ChangeLog 对应条目核查修复内容 |
| 第 5 组 | 8.1.32、8.1.33、8.1.34 | 以官方 ChangeLog 对应条目核查修复内容 |
以上清单来自 PHP 官方仓库标签的交叉核验。它用于防止在运维文档、镜像标签或升级单中漏写、错写、或把预发布版本误当成稳定版。尤其在多台主机并存时，建议同时记录 CLI、FPM 和队列进程各自实际加载的版本。
如何阅读 ChangeLog，而不是只看“修复了什么”
| 阅读位置 | 应回答的问题 | 行动 |
|---|---|---|
| Core / Opcache | 是否影响语言执行、JIT、内存或预加载 | 建立回归用例，关注异常和峰值内存 |
| 扩展条目 | 是否启用该扩展，是否处理不可信输入 | 对启用扩展、接口和文件格式做专项测试 |
| 安全公告 | 受影响版本和修复范围是什么 | 安排最短可行的维护窗口，并保留回滚制品 |
| 构建与平台 | 系统库、Windows 或特定 SAPI 是否受影响 | 在同类操作系统、容器基础镜像上验证 |
部署前后核对清单
bash
# 部署前：记录基线与目标版本
php -v
php -m | sort > /tmp/php-8.1-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 官方资料为准；在实际变更前，仍应在与生产尽量接近的环境中完成验证。