preg_match匹配不到的常见错误包括：未用u修饰符导致中文匹配失败、定界符未闭合、^$在多行中未加m修饰符、.不匹配换行符需加s修饰符；用户名验证须用\x{4e00}-\x{9fff}加u修饰符，首字符单独限定，量词控制总长。
preg_match 为什么匹配不到，常见错误有哪些
多数人写 preg_match 失败，不是正则本身错，而是忽略了 PHP 正则的定界符、修饰符和转义规则。比如想匹配中文，写成 /中文/ 会报错 —— 因为默认 PCRE 使用 UTF-8 编码，但没加 u 修饰符，中文 被当成非法字节序列。
常见错误现象：
-
Warning: preg_match(): Compilation failed：正则语法错，或定界符没闭合（如写成/abc漏了结尾/） - 空数组或
false返回：模式写对了，但目标字符串里根本没匹配项；或用了^/$却没加m修饰符，在多行文本中失效 - 匹配结果少一个字符：忘了正则里的
.默认不匹配换行符，要加s修饰符才能让.匹配包括\n在内的所有字符
如何安全写出带中文、数字、下划线的用户名验证正则
真实场景里，用户名常要求「2–16位，字母开头，允许中文、数字、下划线」。直接拼 [a-zA-Z\u4e00-\u9fa50-9_] 是错的 —— \u4e00-\u9fa5 只覆盖常用汉字，且 PCRE 不识别 \u 形式 Unicode 转义（除非用 u 修饰符 + \x{4e00} 写法）。
正确写法示例：
立即学习“PHP免费学习笔记（深入）”；
$pattern = '/^[a-zA-Z\x{4e00}-\x{9fff}][a-zA-Z\x{4e00}-\x{9fff}0-9_]{1,15}$/u';
preg_match($pattern, $username, $matches);
关键点：
- 必须加
u修饰符，否则\x{4e00}无法解析 - 开头单独限定首字符为字母或汉字，避免数字或下划线打头
- 量词用
{1,15}，因为首字符已占 1 位，总长 ≤16 - 别用
\w替代 —— 它在非u模式下只匹配 ASCII 字母数字下划线，中文直接被忽略
preg_match 和 preg_match_all 的行为差异与性能影响
preg_match 找到第一个就停，preg_match_all 扫完整个字符串。这不只是功能区别，还直接影响 CPU 和内存占用。
使用场景判断：
- 校验类（邮箱、手机号、密码强度）→ 用
preg_match，够用且快 - 提取多个同类内容（日志里的 IP、HTML 中所有
href）→ 必须用preg_match_all，但要注意PREG_SET_ORDER和PREG_PATTERN_ORDER返回结构不同 - 大文本（>1MB）中做简单存在性判断 → 加
PREG_NO_ERROR并配合strpos预检，避免正则引擎全量扫描
一个容易被忽略的坑：preg_match_all 在无匹配时返回 0，不是 false，所以不能用 if (preg_match_all(...)) 判定成功，得用 === false 或检查返回值是否 > 0。
替换特殊字符时，为什么 preg_replace 比 str_replace 更危险
很多人以为正则替换更强大，就一律上 preg_replace，结果把 $、{、[ 这些字符当普通文本传进去，引发解析错误或意外替换。
安全做法：
- 纯字面量替换（比如把
"&"换成"&"）→ 优先用str_replace，零正则开销，不担心转义 - 必须用正则替换时，对用户输入的搜索关键词先调用
preg_quote($keyword, '/')，第二个参数要和你的定界符一致 - 避免在替换字符串里写
$1、$2—— 如果只是想输出字面量$1，得写成\$1，否则会被解释为反向引用 - PHP 7.4+ 支持
str_replace数组批量替换，性能远超循环调用preg_replace
复杂点在于：正则的“方便”是有代价的 —— 每次调用都触发编译，而 str_replace 是 C 层直接 memcmp。真要高频替换，先 benchmark 再决定用哪个。
