PHP 8.5.12 怎样查看修订版变化

如果你想知道 PHP 8.5.12 到底改了什么，最稳妥的入口不是只看 php -v 的版本号，也不是把 PHP 8.5 的新特性列表当成 8.5.12 的修订说明。PHP 8.5.12 是 PHP 8.5 分支的一次安全修订版，具体变化应以官方 Release Announcement 和对应的 ChangeLog 条目为准，再结合下载包或平台构建信息判断自己的环境是否真正完成升级。

官方地址：https://www.php.net/releases/8_5_12.php

变更清单：https://www.php.net/ChangeLog-8.php#8.5.12

下载入口：https://www.php.net/downloads.php?source=Y

先把 8.5.12 放回 PHP 的版本层级

PHP 版本阅读可以先拆成三层：8 是主版本，5 是特性分支，12 是该分支上的修订发布。本文只讨论第三层，也就是 PHP 8.5.12 相对 PHP 8.5 同一分支前一版的维护变化；PHP 8.5 首次发布时的 URI 扩展、管道运算符和 clone() 语法等大版本内容，应查看 PHP 8.5 的升级说明，而不是混进本次修订清单。

官方 8.5.12 发布公告将这次发布标为安全发布，并建议 PHP 8.5 用户升级。它给出了发布性质和官方 ChangeLog 入口，但不会把每个 Core、扩展或构建细节都展开。因此，“公告确认范围、ChangeLog 确认条目、下载页确认包”的组合，比只读一个页面更可靠。

用本机信息确认自己正在看的版本

查阅官方资料之前，先把本机运行时的身份记下来。命令行输出可以帮助你判断当前是 PHP 8.5 的哪个修订版、使用了哪个 SAPI，以及配置文件从哪里加载。它只负责识别环境，不会替代 ChangeLog。

# 查看运行时版本、构建信息和 SAPI 相关摘要
php -v

# 查看 CLI 实际加载的配置文件路径
php --ini

# 输出扩展列表，升级后可与留档逐项对照
php -m

如果命令行显示的是 8.5.12，只能说明 CLI 使用的运行时已经报告这个版本。Web 请求可能由另一个 PHP-FPM、Apache 模块或容器提供，因此生产排查还要记录对应 SAPI 和部署单元。若 Windows 下载页显示 8.5.12-1，要把它记在“构建或依赖”字段中，同时把运行时版本记为 8.5.12。

先看发布公告，再读 8.5.12 的 ChangeLog

查修订变化时建议保持固定的阅读顺序。第一步看 Release Announcement，确认版本、发布时间、发布性质和官方入口；第二步打开 ChangeLog 的 8.5.12 小节；第三步按组件分组，把与自身扩展和部署方式有关的条目摘出来。

PHP 8.5.12 的 ChangeLog 包含 Core 等组件的修复项，其中既有安全修复，也有崩溃、断言、垃圾回收和运行时行为相关的修复。阅读时不要把每一条都改写成“新增功能”：修订版条目通常是缺陷修复、安全修复或兼容性维护，升级后的价值更多体现在风险收敛和运行稳定性上。

区分源码修订与 Windows 8.5.12-1 构建

PHP 官方下载页把当前稳定的 PHP 8.5 源码包列为 php-8.5.12。官方首页随后还说明，Windows 构建更新为 8.5.12-1，这类 -1 后缀表示依赖重建，运行时版本仍然是 PHP 8.5.12。这个区别很重要：你需要升级 Windows 构建，不等于 PHP 语言层又出现了一个“8.5.13”或新的特性版本。

如果团队同时维护 Linux 源码包、发行版包和 Windows 构建，建议在升级单上拆成三列：运行时版本、打包或构建标识、依赖变化。这样既能把同一 PHP 修订版归拢在一起，也不会丢掉平台构建的安全更新。

这段 PHP 只用于说明“运行时版本”和“打包构建标识”应分开记录，不能从 PHP_VERSION 推断 Windows 的依赖构建后缀。后缀需要回到官方下载页、发行版包信息或构建系统的制品记录中确认。

把 ChangeLog 条目映射到升级前后的检查项

读完条目后，不要把整段 ChangeLog 原样贴进发布记录，而应按自己的环境做一次映射。Core 条目通常需要关注启动、请求处理和异常行为；扩展条目要看是否安装并启用了对应扩展；安全修复则要进入升级优先级和回滚准备。应用回归关注的是自己的入口、队列、文件、数据库连接和错误处理，不是臆测某个条目一定会改变业务结果。

1. 建立升级前基线：保存 php -v、php --ini、php -m 的结果，以及当前部署包和回滚位置。
2. 摘录相关条目：从 ChangeLog 中记录 Core、安全和已启用扩展对应的条目；无关组件可以保留链接，不必扩写。
3. 核对配置与依赖：比较 PHP 配置、扩展版本、FPM 或 Web 服务器连接方式，尤其注意平台包是否带有单独的依赖更新。
4. 执行应用回归：优先检查登录、核心请求、定时任务、队列、文件上传和数据库连接等真实路径，并保留错误日志摘要。
5. 完成版本留档：同时写入运行时版本、构建标识、升级时间、回归结论和回滚制品，方便下次修订版比较。

常见误区与速查表

最终可以把一次修订查看压缩成一句话：先用官方发布公告确认“是什么”，再用 ChangeLog 确认“改了什么”，用下载页确认“拿到哪个包”，最后用本机信息和应用回归确认“环境是否真的完成升级”。这样记录 PHP 8.5.12，既不会把大版本特性混进修订说明，也不会遗漏 Windows 构建和实际 SAPI 的差异。

相关问题

PHP 8.5.12 和 PHP 8.5.12-1 是同一个版本吗？

运行时版本仍然是 PHP 8.5.12；-1 通常用于标识更新后的平台构建或依赖重建。记录时将两者分别放入运行时版本和构建标识字段。

只看 PHP ChangeLog 就够了吗？

如果目标是了解条目，ChangeLog 是核心资料；如果目标是确认是否完成升级，还需要结合发布公告、下载页、本机 SAPI、扩展和应用回归结果。

升级修订版前为什么要记录扩展？

修订影响可能落在 Core，也可能落在某个扩展或平台依赖。记录已启用扩展可以把官方条目与自己的运行环境对应起来，减少升级后才发现部署差异的情况。