preg_match() 返回 false 时需用 preg_last_error() 判断错误类型：PREG_BAD_PATTERN_ERROR 表示正则语法错误，返回 0 表示匹配失败；错误信息可用 preg_last_error_message()（PHP 7.2+）获取。
preg_match() 返回 false 时怎么判断是语法错还是匹配失败
PHP 的 preg_match() 在正则写错（比如括号不配对、非法转义）时返回 false，但空字符串或没匹配上也返回 0——这两者看起来一样，实际原因天差地别。不能只靠返回值判断是否出错。
正确做法是配合 preg_last_error() 和 preg_last_error_message()：
if (preg_match('/[a-z+/', 'abc') === false) {
$error = preg_last_error();
$msg = preg_last_error_message();
// $error 是整数常量，比如 PREG_BAD_UTF8_ERROR
// $msg 是字符串，如 "Compilation failed: missing ) at offset 5"
}-
preg_last_error()必须在preg_match()等函数调用后立即检查，中间穿插其他 PCRE 函数会覆盖它 - 常见错误码：
PREG_NO_ERROR（正常）、PREG_BAD_PATTERN_ERROR（正则本身语法错）、PREG_BAD_UTF8_ERROR（UTF-8 字节序列非法） - 注意：
preg_last_error_message()PHP 7.2+ 才有，低版本只能靠preg_last_error()查表比对
PCRE 编译阶段就报错：Warning: preg_match(): Compilation failed
这种警告说明正则字符串在编译时就被 PHP 拒绝了，根本没走到执行匹配那步。典型场景是动态拼接正则时漏转义、多了一层斜杠、或用了不支持的语法（比如 JS 风格的 \d+ 在 PCRE 中没问题，但 (? 在旧版 PCRE 中可能不支持）。
- 检查分隔符是否成对：写
preg_match('/[a-z/', $str)就会报错，因为结尾缺/ - 用户输入内容直接进正则？必须用
preg_quote($user_input, '/')转义，否则$user_input = 'a[b'会让正则变成/a[b/，直接编译失败 - PCRE 版本影响行为：Ubuntu 18.04 自带 PCRE 8.39，不支持
\p{Han}；PHP 8.0+ 默认 PCRE2，支持更好，但u修饰符仍需确保输入是合法 UTF-8
匹配过程超时或爆栈：PREG_JIT_STACKLIMIT_ERROR 或 PREG_BACKTRACK_LIMIT_ERROR
不是语法错，但程序卡住或返回 false，常见于处理长文本 + 复杂正则（比如嵌套量词、大量回溯）。PHP 默认回溯上限是 100 万次，JIT 栈默认 32K，一超就硬中断。
立即学习“PHP免费学习笔记（深入）”；
- 临时调高限制（不推荐长期用）：
ini_set('pcre.backtrack_limit', '10000000')或ini_set('pcre.jit', '0')关闭 JIT - 更治本：简化正则。例如把
.*改成[^"]*限定字符范围，避免灾难性回溯 - 用
mb_系列函数替代正则做简单操作：查子串用mb_strpos()，取长度用mb_strlen()，比preg_match()快且无风险
为什么加了 u 修饰符反而报错
u 修饰符要求整个字符串是合法 UTF-8，一旦输入含乱码字节（比如 GBK 编码的中文混进 UTF-8 字符串），preg_match() 直接返回 false，preg_last_error() 是 PREG_BAD_UTF8_ERROR 或 PREG_BAD_UTF8_OFFSET_ERROR。
- 先校验再匹配：
if (!mb_check_encoding($text, 'UTF-8')) { /* 转换或报错 */ } - 不要假设
$_POST或文件读入内容就是 UTF-8；浏览器提交、数据库字段编码、文件保存编码都可能不一致 -
iconv('GBK', 'UTF-8//IGNORE', $text)可过滤非法字节，但会丢失信息；更稳妥的是统一源头编码
正则错误最麻烦的不是看不懂提示，而是错误被静默吞掉，或者在生产环境才暴露。每次写 preg_* 都该默认加一层错误检查，尤其涉及用户输入或外部数据时。
