preg_match返回0表示匹配失败但正则语法正确，返回false才表示正则错误或运行异常；需用===严格比较，并用preg_last_error_msg()查错因。
preg_match 返回 0 和 false 完全不是一回事
返回 0 表示「正则语法正确，但没找到匹配」；返回 false 才是「正则本身写错了或运行出问题」。很多人一看到没匹配就去改正则，结果发现根本没执行——因为函数早就因语法错误失败了。
必须用严格比较：if ($result === false) 判断是否出错；if ($result === 0) 才表示没匹配到。
出错时立刻调用：preg_last_error_msg() 查具体原因，比如：
-
"Unknown modifier 'x'"→ 分隔符没配对，或结尾多了字母 -
"No ending delimiter"→ 忘写右分隔符，如'/abc'漏了/ -
"Backtrack limit exhausted"→ 正则太复杂，触发 PCRE 回溯限制（需调大pcre.backtrack_limit或重写模式）
分隔符不配对是最常见的 false 根源
PHP 的 preg_match 要求模式必须由一对相同非字母数字字符包裹，常见用 /、#、~。一旦内部字符和分隔符冲突又没转义，解析直接崩。
典型翻车现场：
-
preg_match('/https://example.com/', $str)→ 第二个/被当成结束符，后面example.com/变成非法修饰符 -
preg_match('/[a-z]+/', $str)→[被误读为修饰符起始，报Unknown modifier '['
解决方法：
- 换分隔符：
preg_match('#https://example\.com#', $str) - 转义原分隔符：
preg_match('/https:\/\/example\.com/', $str) - 优先用单引号写模式，避免双引号里反斜杠被 PHP 提前吃掉
UTF-8 字符匹配失败？大概率缺 u 修饰符
匹配中文、emoji 或带音标的西文时，不加 u 修饰符，preg_match 很可能返回 false 或只截半字节——PCRE 默认按单字节处理，UTF-8 多字节序列直接乱套。
正确姿势：
-
preg_match('/你好/u', $str)——u必须紧贴右分隔符 - 确保
$str真的是 UTF-8 编码，可用mb_detect_encoding($str) === 'UTF-8'验证 - 若来源不可控，先做转换：
$str = mb_convert_encoding($str, 'UTF-8')
漏掉 u 时，preg_last_error_msg() 不一定报错，而是静默失败或部分匹配，最难排查。
传入非字符串类型导致无声失败
preg_match 的第二个参数 $subject 必须是字符串。传 null、array、int 或未定义变量，函数直接返回 false，且不报 Warning（尤其在 error_reporting 关闭时）。
高频踩坑点：
-
trim($_GET['q'])返回false（当$_GET['q']是数组时），再喂给preg_match就崩 -
json_decode($json)失败返回null，后续直接进preg_match也崩
防御性写法：
- 检查类型：
if (!is_string($str)) { /* 处理异常 */ } - 强制转字符串（谨慎）：
(string) $str，但要注意null变成''可能掩盖问题 - 调试时加一行：
var_dump(gettype($str), $str);
真正难缠的不是正则写得有多复杂，而是那些不报错、不提示、只默默返回 false 的情况——分隔符、编码、输入类型，三者任何一个没对齐，preg_match 就会拒绝工作，而且连句抱怨都没有。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
