PHP preg_match 为什么要区分 0 和 false：匹配失败、正则错误与日志定位

线上表单校验最容易被忽略的一处判断，是把 preg_match() 的返回值直接当成布尔值使用。返回 0 时，正则已经正常运行，只是没有找到匹配；返回 false 时，才需要继续查正则表达式、输入编码或 PCRE 运行错误。两种结果混在一起，日志里就会出现“格式不对”和“规则坏了”互相覆盖的情况。

先看清 preg_match 的三个返回状态

以手机号字段为例，业务通常只想知道“格式是否通过”，但日志和监控还需要知道失败的性质。PHP 手册定义的返回值是整数 1、整数 0 或布尔值 false。它们的数据类型和含义都不同。

这里别写 if (!preg_match($pattern, $phone)) 就结束了。这个写法会把“用户输错手机号”和“程序里的正则已经失效”合并成同一种反馈，短期看省了一行代码，排查时却少了一条关键证据。

用严格比较把用户错误和程序错误分开

把匹配结果先存下来，再依次判断 === false、=== 1 和 === 0。示例里的规则只用于演示大陆手机号的常见格式，具体业务还要结合号段和产品要求调整。

 'phone',
        'pcre_error' => preg_last_error(),
    ], JSON_UNESCAPED_UNICODE));
    $message = '校验规则暂时不可用，请稍后重试。';
} elseif ($matched === 0) {
    $message = '请输入 11 位手机号。';
} else {
    $message = '';
}
?>

0 分支是预期的业务结果，不应该按系统故障报警；false 分支才进入日志和告警。即使当前规则看起来很简单，也建议保留这个分层，因为后续规则往往会加入 Unicode、分组或动态拼接片段。

返回 false 时，先查 preg_last_error()

出现 false 后不要马上放宽正则。先把错误码写入结构化日志，同时保留规则版本、字段名和输入长度；不要记录身份证号、手机号等原始敏感数据。下面的日志足以定位问题，又不会把用户输入完整落盘。

 'phone-v1',
        'length' => strlen($phone),
        'pcre_error' => preg_last_error(),
    ];
    error_log('phone pattern failed: ' . json_encode($context));
}

如果规则带有 u 修饰符，输入不是合法 UTF-8 时尤其要注意。此时问题可能在数据源、转码或数据库连接，而不是手机号本身。日志中的错误码应和发布版本一起看，避免只凭页面提示猜原因。

一个可复现的坏输入检查

调试时可以构造一段含无效字节的字符串，观察带 u 的规则和错误码变化。测试代码放在本地或测试环境，不要把这类原始字节直接写入生产日志。

错误码的具体常量和值要以当前 PHP 与 PCRE 构建为准，生产判断不要硬编码某一个数字。更稳妥的方式是把“返回 false”作为错误分支，再把 preg_last_error() 的结果送进可搜索日志。

常见误区：比较符和动态规则

最常见的 bug 有两个。第一，把返回值和 true 比较；1 === true 为假，会让正常匹配也走到错误分支。第二，把用户配置直接拼进正则，导致定界符、转义或量词异常。动态片段必须经过明确的转义和白名单处理，不能把输入当成规则。

 false, 'reason' => 'not_match'];
}
return ['ok' => true];

这段返回结构比直接返回真假更容易被控制器、接口和日志共用：用户得到可理解的校验提示，运维又能从异常分支看到规则问题。

上线前用三组输入做回归

每次修改规则至少保留三组测试：一个明显匹配的值、一个格式正确但不匹配的值，以及一个会触发错误处理的坏编码值。检查点不是只看页面颜色，还要核对返回类型、日志字段和报警是否符合预期。

• 匹配样例：返回整数 1，进入正常业务流程。
• 未匹配样例：返回整数 0，只显示字段提示，不触发系统告警。
• 异常样例：返回 false，日志包含规则标识、输入长度和 PCRE 错误码。

相关问题

为什么不建议只用 if (!preg_match())？

因为它会把返回 0 和 false 都当成假值，用户输入错误与程序规则错误无法区分。校验逻辑至少应先判断 === false。

preg_match 返回 0 算异常吗？

不算。它表示正则调用成功但没有匹配，是业务校验中正常存在的结果。

preg_last_error() 应该记录什么？

建议连同规则版本、字段名和输入长度记录，不要把手机号、身份证号等原始敏感值完整写进日志。

小结

preg_match() 的返回值要按类型和含义分别处理：1 是命中，0 是未命中，false 才是调用错误。先严格判断错误，再处理业务不匹配，最后用一组固定回归输入核对页面、日志和告警，正则规则才不会从一个简单校验点变成难追的线上故障。