从 PHP 8.3 升级到 PHP 8.4，最容易出问题的往往不是新语法本身，而是旧代码、依赖包和部署环境中默认存在的行为假设。本文把升级拆成可验证步骤，避免用“测试通过了”掩盖测试范围不足。
升级原则：先在与生产等价的依赖与扩展组合中运行目标 PHP 8.4，通过静态分析、自动化测试和灰度观测后再扩大流量。任何失败都应形成可回归的测试用例。
本次跨版本的重点变化
PHP 8.4 的官方迁移指南应作为完整清单；在工程实践中，优先排查：属性钩子与新 Dom API 的采用边界、隐式可空参数弃用、部分扩展转至 PECL、类型化常量与 exit() 行为。
| 检查维度 | 问题示例 | 验证方法 |
|---|---|---|
| 自有代码 | 弃用语法、动态对象字段、类型约束 | 静态分析 + 错误日志转换为失败项 |
| Composer 依赖 | 包声明的 PHP 平台要求过旧 | composer check-platform-reqs 与上游 release notes |
| 扩展与系统库 | FPM、CLI、worker 扩展不一致 | php -m 对比 + 业务依赖 smoke test |
| 发布过程 | 同一时刻运行多套二进制 | 运行时版本日志与服务健康检查 |
从代码扫描到修复
php
// 8.4：属性 hook 要配套测试读写与序列化边界
final class Price {
public int $cents {
set (int $value) { $this->cents = max(0, $value); }
}
}示例只表达目标版本的写法，不代表所有旧代码都应机械替换。尤其是属性钩子、管道运算符等能力，应先确认团队规范、框架版本和静态分析器均支持，再逐步采用。
bash
# 在目标版本容器/主机中执行，而不是仅在本机执行
php -v
composer install --no-interaction --prefer-dist
composer check-platform-reqs
php vendor/bin/phpunit
# 允许时可加入静态分析或框架的测试命令灰度与回滚设计
- 用目标 PHP 8.4 构建单独制品，保留当前生产制品的 digest 或包版本；
- 先切一小部分无状态 Web 流量，观察错误率与关键接口；
- 确认队列、Cron、CLI 工具也已使用目标运行时；
- 出现新增致命错误、类型异常或扩展加载失败时，立刻切回旧制品并把最小复现加入测试。
| 信号 | 含义 | 处置 |
|---|---|---|
| 弃用日志激增 | 尚未修正的未来兼容风险 | 按调用栈建立修复任务 |
| FPM 启动失败 | ini/扩展/ABI 不兼容 | 恢复上一制品，逐项比对模块 |
| 仅队列报错 | CLI 或 worker 版本未同步 | 独立核验 worker 镜像与 Supervisor 配置 |
| 延迟变化 | 可能是缓存、JIT 或依赖差异 | 使用相同流量与配置做可重复比较 |
结语
PHP 版本升级不是把二进制文件替换掉就结束了。更可靠的路径是先确认支持状态与升级边界，再让依赖、测试、部署和回滚共同构成闭环。本文的版本结论以 PHP 官方资料为准；在实际变更前，仍应在与生产尽量接近的环境中完成验证。