PHP 8.5 升级生存指南：避免凌晨两点回滚的检查清单
PHP 8.5 升级生存指南：避免凌晨两点回滚的检查清单升级 PHP 不难，被坑才难
一月初是做那种"你永远不想赶工"的工作的好时机：运行时升级。
大多数 PHP 8.x 小版本升级很顺利，但"顺利"不等于"零风险"。真正的问题通常来自：
[*]隐藏的平台约束（扩展、系统库、SAPI），
[*]能编译但行为不同的依赖，
[*]被忽略多年的警告/弃用突然淹没日志，
[*]假设回滚"很简单"的上线计划（实际上很少简单）。
这篇文章侧重实操。我不会重新讲 PHP 8.5 的新特性，比如管道操作符或 URI 处理。新特性只会作为兼容性检查点简单提及。目标是像成年人一样发布 PHP 8.5：有计划、有防护、有监控、有真正能用的回滚路径。
PHP 8.5 的稳定版于 2025 年 11 月 20 日发布，遵循正常的 PHP 支持周期。
原文 PHP 8.5 升级生存指南：避免凌晨两点回滚的检查清单
确定目标版本，定义内部支持策略
在动 CI 或 Composer 之前，先回答一个问题：
在你的组织里，这次升级"完成"意味着什么？
确定目标和截止日期
PHP 分支有两年的活跃支持，然后是两年的安全修复。
官方支持表：
[*]PHP 8.5：2025 年 11 月 20 日初始发布
[*]活跃支持至 2027 年 12 月 31 日
[*]安全支持至 2029 年 12 月 31 日
支持窗口很宽裕——但你的内部截止日期通常由以下因素驱动：
[*]合规要求，
[*]托管镜像 / 基础容器，
[*]框架支持窗口，
[*]停留在"仅安全修复"阶段的成本。
定义范围（升级常常在这里无声失败）
写下什么包含、什么不包含：
包含：
[*]运行时版本升级（FPM/CLI），
[*]Composer 依赖调整，
[*]CI 矩阵更新，
[*]生产环境上线策略，
[*]升级后验证。
不包含（除非你明确加进去）：
[*]重构代码以使用 PHP 8.5 新特性，
[*]与 PHP 8.5 无关的主要框架升级，
[*]"顺手改"的重写。
如果不定义范围，"升级"会变成"重写"，然后就会停滞。
提前决定兼容性策略
如果代码库需要在旧版 PHP 和 8.5 上同时运行一段时间：
[*]用 CI 强制双版本兼容，
[*]在生产环境切到 8.5 之前，不要合并 8.5 专属语法（比如 |>）。
如果做硬切换：
[*]确保上线/回滚方案万无一失，
[*]接受功能分支可能更早开始使用 8.5 专属语法。
初始审计：当前 PHP、扩展和依赖约束
大多数"PHP 升级"bug 不是语言 bug，而是环境不匹配。
快照实际运行的运行时
在生产环境运行这些命令，不是你的笔记本：
php -v
php -m
php --ini
php -i | head -n 50如果用 PHP-FPM，还要捕获：
[*]FPM pool 配置，
[*]ini 覆盖，
[*]传给 FPM 的环境变量，
[*]opcache/JIT 设置（这些在不同环境可能不同）。
创建可复用的"平台快照"脚本
把这样一个脚本放到 tools/php-platform-snapshot.php，在每个环境（开发/预发/生产）运行。提交脚本本身，不要让它成为口口相传的知识。
不错，里面软件多更新就更好了 懂技术并乐意极积无私分享的人越来越少。珍惜 感谢分享，学习下。 感谢，下载保存了 感谢分享，学习下。 感谢，下载保存了 谢谢分享，辛苦了 谢谢楼主提供！ 不错，里面软件多更新就更好了 很好很强大我过来先占个楼 待编辑 收藏一下 不知道什么时候能用到 感谢，下载保存了 东西不错很实用谢谢分享 这个好，看起来很实用 感谢发布原创作品，程序园因你更精彩 过来提前占个楼 过来提前占个楼 用心讨论，共获提升！ 鼓励转贴优秀软件安全工具和文档！
页:
[1]
2