preg_match()只匹配一次是因其设计目标为找到首个匹配即停止；需全部匹配应使用preg_match_all()，且需注意utf-8需加u修饰符、邮箱手机号推荐分层验证、警惕回溯爆炸及避免用正则解析复杂结构。
preg_match() 为什么总是只匹配一次？
因为 preg_match() 的设计目标就是「找第一个匹配就停」。它返回 1（成功）、0（没找到）或 false（正则语法错），不关心后面还有没有。如果你需要全部匹配，得换函数。
常见误用场景：用 preg_match() 去提取 HTML 中所有 <a href="..."></a> 链接，结果只拿到第一个——这不是 bug，是预期行为。
- 要全量提取，请改用
preg_match_all() - 注意
preg_match_all()第三个参数是引用传入的数组，别漏掉&$matches - 默认返回二维数组：
$matches[0]是完整匹配项，$matches[1]是第一个捕获组
中文、emoji、生僻字匹配总失败？看 PCRE 模式修饰符
PHP 默认的 PCRE 引擎把字符串当字节流处理，遇到 UTF-8 编码的中文或 emoji 就容易断在中间，导致 preg_match() 返回 false 或匹配不全。
解决方法很简单：在正则模式末尾加上 u 修饰符，启用 UTF-8 模式。
// 错误：没加 u，可能匹配失败或乱码
preg_match('/\w+/', '你好123', $m);
// 正确：加 u 后 \w 能识别中文、日文等 Unicode 字母数字
preg_match('/\w+/u', '你好123', $m); // 匹配到 "你好123"
// 注意：\d、\s 等也受 u 影响；\p{Han} 这类 Unicode 属性必须带 u 才生效
preg_match('/\p{Han}+/u', '你好世界', $m); // 匹配中文字符
验证邮箱、手机号时，别直接抄网上“万能正则”
所谓「邮箱正则」/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/ 看似全面，但实际会拒绝合法邮箱（如 "john..doe"@example.com），也会放过明显非法的（如 user@.com）。
真实项目中推荐分层验证：
- 前端用简单正则快速拦截明显错误（比如没 @、没点）
- 后端优先用
filter_var($email, FILTER_VALIDATE_EMAIL)—— 它基于 RFC 5322，比手写正则更靠谱 - 真正关键的业务（如注册），必须走邮件确认链路，正则只是第一道过滤网
手机号同理：filter_var($phone, FILTER_SANITIZE_NUMBER_INT) 清洗后再按国家区号规则判断长度，比硬套 ^1[3-9]\d{9}$ 更健壮。
性能差？可能是正则回溯爆炸了
当正则里出现嵌套量词（比如 (a+)+b）且输入文本不匹配时，PCRE 可能尝试指数级回溯路径，CPU 瞬间拉满，请求超时。
典型症状：某条 preg_match() 在测试数据上秒出，一到线上就卡住几秒甚至超时。
- 用
preg_last_error()检查是否触发了PREG_BACKTRACK_LIMIT_ERROR - 避免
.*开头的贪婪匹配，改用非贪婪.*?或明确边界（如[^"]*替代.*匹配引号内） - 对用户输入的正则（如搜索高亮）务必加
set_time_limit(1)或用pcntl_alarm()做兜底
正则不是万能胶，复杂结构解析（如 JSON、HTML）请交给专用解析器，别硬刚。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
