PHP 8.4 升级后隐式可空参数为什么报弃用：?string、null 默认值和改造顺序

把项目切到 PHP 8.4 后，很多团队先看到的不是业务报错，而是函数声明旁边出现弃用提示：string $prefix = null 这类写法需要改成显式可空类型。它不是让调用方停止传 null，而是要求把“可以为空”写进签名，方便类型检查、继承兼容和后续升级都按同一套规则理解。

先确认这次升级影响的是哪一类签名

问题集中在“有类型声明，同时默认值写成 null”的参数上。旧版本会把它理解为可接收空值，因此不少 DTO、格式化工具和仓储层方法沿用了这种写法。PHP 8.4 要求把这层语义明确写出来，发布说明也把它列为兼容性相关的弃用项。

不要把这个提醒和“内置函数收到 null”混在一起。这里讨论的是你自己声明的参数类型；处理的入口是函数、方法和闭包的签名，而不是某一次调用传了什么值。

第 1 步：用一个旧方法复现提示

先从一个规模很小的方法开始。下面的 makeLabel() 允许省略前缀，也允许显式传入 null，但可空语义没有出现在 string 前面。

在升级分支里加载这个文件，再观察弃用输出即可确认命中点。检查时不要只看接口层：服务类、事件监听器、测试辅助方法和闭包参数同样可能藏着这类声明。

第 2 步：按项目版本基线改成显式类型

如果代码库仍需要兼容 PHP 7.1 到 7.4，使用 ?string 最稳妥；这个语法从 PHP 7.1 起就能表达单一类型可为空。项目最低版本已经是 PHP 8.0 时，string|null 与它表达的集合相同，团队可以按既有类型风格统一选择。

这一步通常不改变正常调用结果：makeLabel()、makeLabel(null, 'alice') 和 makeLabel('team', 'alice') 的分支仍然清楚。真正改变的是声明本身不再依赖默认值去推断类型边界。

参数后面还有必填参数时，别只机械加问号

需要单独检查的是“默认值参数排在必填参数前面”的旧签名。PHP 手册说明，这类参数在较新版本里可能仍需要由调用方显式传入；所以迁移时先问一句：这个 null 默认值是否真的代表“可省略”？

如果产品语义确实允许省略筛选条件，更清晰的做法是调整参数顺序，或拆出一个只接收必填字段的方法。这样既处理弃用提示，也不会让调用端误以为第一个参数可以直接跳过。

第 3 步：扫描命中点后分批验证

一次性替换前，先在升级分支做候选扫描。正则的目的只是找候选，不应当直接批量改写：复杂联合类型、接口实现和生成代码都值得人工确认。

rg -n 'function\s+\w+\([^)]*\$\w+\s*=\s*null' src tests
php -l src/LabelMaker.php
vendor/bin/phpunit

每个批次至少核对三件事：声明里不再依赖 = null 推断可空；原有传入 null 的测试仍符合业务预期；继承方法或接口实现的类型兼容没有被破坏。对公共库而言，还要把最低 PHP 版本写进发布说明和持续集成矩阵。

迁移顺序可以按风险收敛

我更倾向于先改内部工具方法，再处理跨模块接口，最后才碰公开 SDK。内部方法的调用面小，能先验证团队的类型风格；接口和抽象类则要把实现方一起纳入检查，避免某个实现类落下后才在集成环境暴露问题。

1. 锁定应用实际使用的 PHP 版本，并在升级分支打开弃用输出。
2. 扫描函数、方法和闭包的候选签名，标记公共接口与继承关系。
3. 按最低版本选择 ?Type 或 Type|null，不要混用成两套无法解释的规则。
4. 逐批运行语法检查、单元测试和关键请求回归，再合并到主干。

相关问题

只把 = null 删除可以吗？

不一定。删除默认值会让参数不再可省略，可能改变调用方行为。先确认业务是否允许空值，再决定显式可空还是改成必填参数。

?Type 和 Type|null 应该选哪个？

单一类型时二者表达的可接受值一致。需要兼容 PHP 7.1 到 7.4 时选 ?Type；最低版本为 PHP 8.0 时，可遵循项目既有的联合类型风格。

闭包参数也需要检查吗？

需要。弃用针对参数声明，不限于普通函数；回调、集合处理和测试夹具中的闭包也应纳入扫描范围。

这次改动会让传入 null 的调用立刻失败吗？

显式可空写法仍接受 null。迁移目标是让签名明确表达这一点，而不是把已有的空值分支直接删除。