PHP 的 match 表达式不支持直接用 null 作分支值，因其非标量且无法被编译器静态识别为可哈希模式；用 match(true) 动态判断是反模式，会丧失性能、类型分析和语义清晰性；应优先通过提前过滤、联合类型处理或枚举映射来应对 null。
match 表达式里直接写 null 会报错
PHP 的 match 要求所有分支左侧必须是字面量、常量或枚举成员，而 null 在语法上不被视为可直接用于分支比较的“值字面量”——它不是标量，也没有运行时可比的 identity。所以写成这样会 parse error：
$result = match ($value) {
null => 'is null',
'foo' => 'is foo',
};
这不是 bug，是设计限制：match 的底层匹配逻辑基于 ===，但前提是左侧能被编译器静态识别为一个确定的、可哈希的模式。而 null 在分支位置无法参与这种编译期模式构建。
用 match(true) 匹配 null 是反模式
有人会想绕开限制，写成：
$result = match (true) {
$value === null => 'null',
$value === 'foo' => 'foo',
};
这看似能跑通，但实际踩了三个坑：
立即学习“PHP免费学习笔记（深入）”；
- 每次执行都要重新计算所有条件表达式（
$value === null等），失去 match 的 O(1) 查表性能优势 - PHPStan / Psalm 等静态分析工具无法推断分支覆盖性，
default可能被误报为冗余 - 违反 match 的语义初衷：它本该是「输入 → 输出」的纯映射，而不是带副作用的条件执行块
真正安全且符合设计意图的做法
遇到需要处理 null 的场景，优先用以下方式之一：
- 提前过滤：
if ($value === null) { ... } else { $result = match($value) { ... }; } - 用联合类型 + 默认值兜底：如果
$value声明为string|null，就应在业务逻辑层明确区分空路径，再让非空值进 match - 配合枚举：把
null映射为一个显式枚举成员，例如Status::Missing，再在 match 中匹配该常量
根本问题不在“怎么让 null 进 match”，而在于 match 本身不是为运行时动态判断设计的——它要的是确定、有限、可穷举的离散值空间。一旦出现 null 这种“缺席值”，说明输入契约本身就不适合用 match 直接消化。
