PHP 8.5 发布后怎样规划 8.4 迁移检查

PHP 8.4 项目迁移到 8.5，应先固定现有应用、锁文件与运行配置，再在独立的 8.5 环境确认依赖要求，逐项处理官方不兼容变化和弃用项，覆盖 Web、CLI 与常驻任务，最后准备灰度观察和回退条件。不能仅凭 Composer 安装成功或首页能打开，就认定迁移完成。

面对这种升级计划，我更愿意先拿到一份能解释差异的环境记录，而不是立即采用新语法。这是一种规划取舍：运行时升级与业务重构分开，失败时更容易知道该恢复哪一部分。下面是我会采用的检查安排，不代表某个线上系统已经完成迁移。

PHP 官方迁移入口：https://www.php.net/manual/en/migration85.php

先固定 8.4 基线和 8.5 目标环境

我会先记录应用提交、composer.lock、PHP 完整版本、扩展集合、INI 配置，以及 FPM、命令行和队列进程分别如何启动。8.5 目标环境应明确到实际安装版本与构建来源，不把开发机默认 php 命令当作生产目标。

起点确实为 8.4 时，使用官方 8.4.x 到 8.5.x 迁移文档；更旧的起点还需补上中间版本变化。下面命令用于读者在隔离环境收集 CLI 信息，不会替你切换服务：

# 在准备迁移的 CLI 环境中记录版本、模块和配置文件位置。
php -v
php -m
php --ini

得到这些信息后，先与旧环境逐项对照。输出包含配置文件路径时只存入受控部署记录，不要把完整诊断页公开到网站。实际 FPM 配置需要通过自身部署配置与受限诊断方式确认，CLI 的结果不能直接代替它。

依赖约束通过后仍要比较实际运行环境

我会尽量先保持锁文件不变，识别哪些依赖本身拒绝目标 PHP。如果必须更新某个包，再单独记录其版本变化与回归范围。把所有依赖一起升级，虽然表面上省事，却会扩大差异来源。

Composer 官方文档：https://getcomposer.org/doc/03-cli.md#check-platform-reqs

# 在目标 PHP 的隔离构建环境、已准备好依赖的项目目录执行。
# 确认 composer 使用的是目标解释器；此命令检查生产依赖的真实平台要求。
composer check-platform-reqs --no-dev

该命令检查已安装包的 PHP 与扩展要求，并忽略 config.platform 的模拟设置。通过只说明平台要求满足，不证明框架全部行为正确；--no-dev 也不涵盖开发测试工具。测试工具应在对应测试环境另外确认。

把不兼容项和弃用项分开处理

我会把迁移清单拆成“行为已变”和“仍可运行但应替换”两栏，避免所有警告都按同一种优先级处理。以下是官方文档中可优先映射到项目的例子，不是完整清单。

软弃用不能直接等同于“每次调用都会新增弃用日志”。序列化相关修改尤其需要看旧缓存、旧会话或队列载荷能否继续被读取，不能机械替换方法名。我的做法是对每个命中项写清调用点、影响入口和负责人，而不是只统计关键词数量。

保留服务权限边界并收集弃用日志

升级不会替代原有的账户、目录和密钥权限设计。我会保留独立服务账户与既有最小授权，核对新 FPM 池的运行用户、日志可写目录和密钥注入方式。发现扩展或配置缺失时，先定位具体原因，不把服务改成高权限账户来“先跑起来”。这些是部署建议，具体权限仍由应用实际需求决定。

在隔离环境启用完整错误报告，把警告和弃用记录送到受限日志。生产响应里应关闭错误显示，避免错误文字进入 JSON 或泄露运行细节。以下是 INI 片段示例，需按环境配置实际日志目的地：

; 收集迁移诊断；不把错误直接显示给网站访问者。
error_reporting = E_ALL
display_errors = Off
log_errors = On

我会按应用代码和第三方依赖分别归类，观察登录、上传、导出、序列化、数据库访问和队列消费这些本项目实际存在的入口。一次空闲观察没有新日志，并不代表所有分支都覆盖到了；自定义错误处理器也可能改变日志记录方式。

发布前准备旧环境与业务回退清单

切换前，我会保存可部署的 8.4 旧制品、8.5 新制品和配置版本，并单独写数据兼容说明。运行时回退、代码回退和数据恢复是不同操作：新代码写入旧代码无法读取的内容时，切回旧解释器不能自动解决。

灰度范围应覆盖实际请求与常驻任务，避免 Web 已经换版本但队列仍在旧进程中运行。按项目既有发布方式刷新进程和运行时缓存，记录错误率、延迟与队列积压的基线。停止放量的阈值、观察时段和回退负责人，应在切换前约定；这里不提供脱离业务基线的通用数字。

我认为这套安排适合有 Web 与后台任务的维护项目。极小脚本可以缩减记录量，但仍应保留实际运行环境、关键输入输出和恢复旧环境的方法。最终交付应是一组能说明“改了什么、哪些入口通过、出现什么情况回退”的记录。

必须马上使用 8.5 新语法吗？不必。先完成兼容迁移，再单独采用新语法，更容易划分问题来源。

Composer 通过就可以上线吗？还需要实际业务回归、运行入口一致性和回退准备；依赖平台检查只覆盖其中一部分。

弃用项能否都留到以后？先判断是否影响响应、日志容量和框架错误处理，再排入修复计划；不能仅为消除提示关闭诊断。

官方细项：https://www.php.net/manual/en/migration85.incompatible.php；https://www.php.net/manual/en/migration85.deprecated.php；https://www.php.net/manual/en/errorfunc.configuration.php。