PHP match 表达式没有匹配项为什么会抛异常

PHP match 表达式没有匹配项且未提供 default 时，会抛出 UnhandledMatchError，因为 match 要求覆盖实际传入的值。它使用严格比较，整数 1 与字符串 '1' 不相同；看起来“值一样”的输入，也可能没有命中任何分支。

官方地址：https://www.php.net/manual/en/control-structures.match.php

下面以状态参数的展示与解析为例。目标不是隐藏所有报错，而是让未知输入不能误入正常业务分支。文中代码仅供解释，未在本文制作过程中执行，也不构成真实线上故障记录。

字符串数字为什么绕过了整数分支

假设外部请求带来字符串 '1'，代码却只枚举整数 1 和 2。match 不会替开发者把它转换成整数，因此没有分支成立。下面故意不写 default，展示这个差异：

 '待处理',
        2 => '已归档',
    };
} catch (UnhandledMatchError $error) {
    // 明确演示未覆盖的值，不输出异常原文中的请求内容。
    echo '输入未被任何分支处理', PHP_EOL;
}

按语言规则，这份示例会进入 catch。问题不在于少写 break：match 本来就没有 switch 那种命中后向后贯穿的行为。也不应该为了让它“像 switch 一样”而随意转换所有输入，因为数组、空串和非法数值串可能被错误处理。

为什么 catch Exception 没有兜住它

虽然习惯上把所有抛出的错误都叫“异常”，UnhandledMatchError 实际继承 Error，而不是 Exception。只写 catch (Exception $e) 不能捕获它。需要针对这一问题处理时，可以捕获 UnhandledMatchError；统一请求边界也可以按应用约定处理 Throwable，但不应把所有错误都伪装成业务成功。

UnhandledMatchError、Error、Exception 和 Throwable 的类型关系决定了 catch 能覆盖什么。错误处理要窄到能解释：参数不支持属于预期的输入错误，内部映射漏分支则可能是程序缺陷。把两者一起吞掉并返回“已完成”，会破坏业务状态的可信度。

先按风险选择拒绝未知值，还是显示未知标签

这些是应用设计建议，不是 match 自动提供的安全保证。状态标签函数不能代替权限校验；能够匹配一个值，也不意味着调用者有权修改相应记录。对外部输入，先限定接受集合，再进入内部映射，可以让每层责任更清楚。

把精确接受规则写在输入边界

下面是另一份独立示例：parseState 接受整数 1、2 和精确字符串 '1'、'2'；其余全部抛出 InvalidArgumentException。stateLabel 则只负责内部状态展示。不要将两份示例拼成一个脚本，它们演示的是不同处理方式。

 1,
        2, '2' => 2,
        default => throw new InvalidArgumentException('不支持的状态'),
    };
}

function stateLabel(int $state): string
{
    // 内部映射保留穷尽检查，让将来漏加分支时暴露问题。
    return match ($state) {
        1 => '待处理',
        2 => '已归档',
    };
}

$raw = $_GET['state'] ?? null;
try {
    echo stateLabel(parseState($raw)), PHP_EOL;
} catch (InvalidArgumentException $error) {
    // 边界错误拒绝处理，不把未知状态解释成已归档或已授权。
    http_response_code(400);
    echo '状态参数不受支持', PHP_EOL;
}

这里的 mixed 保留了原始类型，避免函数入口先发生标量转换再匹配。请求参数如果是数组、null、空串或字符串 '01'，都不在本例接受集合内。是否应该接受前后空格或其他编码，要由实际协议决定，不能为了减少错误而自动宽松处理。

示例只捕获预期输入错误。若内部 stateLabel 日后遇到新增但未映射的状态，错误应进入应用已有的统一错误处理与受控日志，而不是被参数错误分支误报成用户输入问题。命名空间代码中还应正确导入或使用这些内置错误类的完整名称。

日志记录类型与位置，不复制完整请求

排查时建议记录请求关联标识、输入类型、映射名称和错误类别；敏感原值按业务规则脱敏。不要把异常原文、完整查询串或堆栈直接返回给用户。尤其不能靠打印所有输入来替代明确的参数契约。

读者自行回归时，可以覆盖整数 1、字符串 '1'、字符串 '01'、null、空串、数组以及尚未定义的状态。分别确认哪些被接受、哪些被拒绝，以及拒绝后没有发生业务写入。本文未执行这些检查，因此不提供通过率或运行截图。

加上 default 就彻底修好了吗？只有 default 的业务含义正确才算修复。无条件返回“正常”只是隐藏遗漏。

declare(strict_types=1) 决定 match 严格比较吗？不是。match 的严格比较是表达式自身规则，和标量参数调用的类型约束不要混为一谈。

必须改成 switch 吗？不必。先理解输入类型及未覆盖值的策略，再选语法；换成宽松比较可能引入另一类错误。

最终应保住两个边界：输入集合要明确，未知值的处理要有业务理由。UnhandledMatchError 提醒的是某个实际值没有被处理，正确做法是补全契约，而不是让所有错误默默落入成功分支。

错误类型参考：https://www.php.net/manual/en/class.unhandledmatcherror.php。