preg_match匹配失败主因是忽略PCRE默认行为、分隔符冲突、元字符未转义及UTF-8缺失u修饰符；返回1成功、0未匹配、false为错误。
preg_match 匹配失败的常见原因
多数人写完 preg_match 发现不匹配，不是正则写错了，而是没注意 PCRE 的默认行为：它只找第一个匹配，且要求整个模式能“贴着字符串开头”连续匹配（除非用了 ^ 显式锚定，否则其实不强制从头开始，但很多人误以为必须完全覆盖字符串）。更常被忽略的是分隔符和转义问题——比如想匹配下划线 _，写成 /_abc/ 看似没问题，但如果用 / 作分隔符，而正则里又含 / 字面量（如路径），就会提前截断；还有像 .、*、+ 这些元字符，在字符串里没加反斜杠就直接拼接，PHP 会当字面量处理，导致逻辑失效。
- 必须用成对分隔符包裹正则，常用
/、~、#，避免和正则内容冲突 -
_是普通字符，无需转义；但.、?、[、]、(、)等在正则中有含义，要字面匹配就得加\ - 中文、emoji 或 UTF-8 多字节字符需加
u修饰符，否则可能截断或匹配异常 - 函数返回
1表示匹配成功，0是未匹配，false才是出错（比如正则语法错误）
匹配带下划线的变量名（如 user_name、API_KEY）
这类命名常见于配置键或数据库字段，规则通常是：字母或下划线开头，后续可跟字母、数字、下划线。注意不能以数字开头，也不能连续两个下划线（除非你明确允许）。
preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', $str)
如果还要支持大驼峰（如 UserName）和蛇形（user_name）混合，可以放宽为：
preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*[a-zA-Z0-9]$/', $str)
- 开头
^[a-zA-Z_]确保首字符合法 - 中间
[a-zA-Z0-9_]*允许任意次数的字母、数字、下划线 - 结尾
[a-zA-Z0-9]$防止结尾是下划线（避免name_这类无效标识符） - 不需要
u修饰符，除非变量名含中文（一般不推荐）
提取 URL 中的域名部分（如从 https://api.example.com/v1 → example.com）
直接用 parse_url() 更可靠，但若必须用正则（比如日志行中混杂文本），关键是要避开协议、路径、端口干扰。常见错误是写 /https?:\/\/([^\/]+)/，结果捕获到 api.example.com:8080 或 api.example.com/v1。
立即学习“PHP免费学习笔记（深入）”；
preg_match('#https?://(?:www\.)?([a-zA-Z0-9.-]+)(?::\d+)?(?:/|$)#i', $logLine, $matches)
说明：
- 用
#当分隔符，避免和 URL 中的/冲突 -
(?:www\.)?是非捕获组，匹配可选的 www.，不占用$matches[1] -
([a-zA-Z0-9.-]+)捕获域名主体，允许点和短横线 -
(?::\d+)?匹配可选端口（如:3000），用零宽断言确保不吞掉后面的/ -
(?:/|$)确保域名后紧跟路径分隔符或字符串结尾 -
i修饰符让http和HTTP都能匹配
为什么 preg_match 不如 preg_match_all？什么时候该换？
preg_match 只返回第一个匹配结果，适合“是否存在某模式”的判断；一旦你需要所有匹配项（比如提取页面中全部邮箱、解析 CSV 行里的多个字段、批量替换前预检），就必须切到 preg_match_all。一个典型陷阱是：用 preg_match 去处理多行日志，以为加了 m 修饰符就能跨行匹配，结果还是只拿到第一行的首个匹配——m 只影响 ^ 和 $ 的行为，不改变“只找一次”的本质。
- 检查是否含敏感词：
preg_match('/(password|secret)/i', $input)—— 足够 - 提取所有电话号码：
preg_match_all('/1[3-9]\d{9}/', $text, $phones)—— 必须用 all - 性能上，
preg_match略快，但差异微乎其微；别为了省一个函数调用牺牲逻辑正确性 - 如果正则里用了
g（全局）修饰符，preg_match会忽略它；只有preg_match_all才响应g
真正难的从来不是写出能跑的正则，而是想清楚你要匹配的边界在哪——是整个字符串？某个单词边界？还是嵌套结构中的最小闭合单元？这些决定分隔符、修饰符、括号分组方式，也决定你最终要不要把 preg_match 换成 preg_replace_callback。
