preg_match 返回0或false最常见的原因是正则分隔符未正确处理或遗漏修饰符；需确保分隔符成对、特殊字符转义，修饰符如i要显式添加，且$matches参数须传变量并初始化。
preg_match 是 PHP 里做正则匹配最常用的函数，但它不是“一写就对”，很多问题出在分隔符、修饰符、数组引用或 PCRE 版本差异上。用错轻则匹配失败，重则空数组或警告。
为什么 preg_match 总是返回 0 或 false？
最常见的原因是正则表达式没写对分隔符，或者忘了加修饰符（比如大小写不敏感要用 i）。PHP 要求正则必须用成对的分隔符包裹，最常用的是 /，但如果你的模式里本身含 /（比如匹配 URL），就得换分隔符或转义。
- 错误写法：
preg_match('/https://example.com/', $str)—— 这里/在 URL 中没转义，会提前结束正则 - 正确写法：
preg_match('#https://example.com#', $str)或preg_match('/https:\/\/example.com/', $str) - 漏修饰符：想匹配
HTML不区分大小写，却写preg_match('//', $str)→ 应该是preg_match('//i', $str) - 注意：如果
$subject是null或非字符串，preg_match会返回false并触发 warning
preg_match 的第三个参数 $matches 怎么安全使用？
这个参数是引用传入的数组，用来存捕获结果。它不是可选的“顺便”，而是你取子串的关键。但很多人忽略它的结构：索引 0 是完整匹配，1 开始才是括号捕获组。
- 必须传变量名，不能传字面量：
preg_match('/(d{4})-(d{2})/', $date, $m)✅；preg_match(..., [], $m)❌（PHP 会报 Warning） - 如果没匹配成功，
$m不会被赋值，直接var_dump($m)可能报undefined variable，建议先初始化：$m = [] - 只想要第一个匹配就用
preg_match；要全部匹配，改用preg_match_all - 示例：
preg_match('/(w+)@(w+.w+)/', 'contact@example.com', $m)→$m[0]是完整邮箱，$m[1]是contact，$m[2]是example.com
和 strpos、str_contains 比，什么时候非用 preg_match 不可？
正则不是万能钥匙。简单子串查找用 strpos 或 PHP 8.0+ 的 str_contains 更快、更安全、无 PCRE 依赖。只有当你需要「模式抽象」时才轮到 preg_match。
立即学习“PHP免费学习笔记（深入）”；
- 适合用：
preg_match('/^d{6}$/', $code)（6位纯数字）、'/^[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,}$/i'（基础邮箱校验） - 不适合用：
preg_match('/hello/', $str)→ 直接str_contains($str, 'hello') - 性能提醒：PCRE 编译正则有开销，高频调用建议把正则字符串定义为常量或静态变量，避免重复编译
- 安全提醒：用户输入拼接到正则中极易导致 ReDoS 或注入，例如
preg_match('/' . $_GET['pattern'] . '/', $str)绝对禁止
真正难的不是语法，而是判断「这里到底需不需要正则」——很多 bug 来自用 preg_match 去干 explode 或 json_decode 的活。另外，PCRE2（PHP 7.3+ 默认）和旧版行为略有不同，比如 Unicode 属性 p{L} 在老版本不支持，上线前最好确认环境版本。
