preg_match_all匹配失败主因是误用返回值及参数：它返回匹配次数而非结果，需传引用变量$matches获取数据；须注意修饰符（s/u）、捕获组索引、PREG_*_ORDER标志差异及避免回溯爆炸。
preg_match_all 匹配失败的常见原因
多数人写完 preg_match_all 没结果，不是正则写错了，而是没注意返回值含义和参数顺序。它**不直接返回匹配内容**，而是返回匹配到的“次数”，匹配结果全存在你传进去的引用变量里。
典型错误写法：if (preg_match_all('/\d+/', $str)) { ... }——这只能判断有没有数字，但你根本拿不到那些数字。
- 必须传入第 3 个参数（
&$matches），且用引用（加&） - 正则中用了捕获组（
()），$matches[0]是完整匹配，$matches[1]才是第一个括号里的内容 - 没加修饰符时，
.不匹配换行符，多行文本要加s修饰符 - 中文或 Unicode 字符需加
u修饰符，否则可能截断字节
提取多个相同结构的数据（如所有邮箱）
这是最常用场景：从一段文本里捞出所有符合格式的子串，比如邮箱、URL、ID。关键在于正则设计要“够窄”，避免过度匹配。
示例：提取邮箱
立即学习“PHP免费学习笔记（深入）”；
$text = '联系我：a@b.com 或 admin@test.org，别发给 invalid@';
preg_match_all('/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/', $text, $matches);
// $matches[0] 是完整匹配数组：['a@b.com', 'admin@test.org']
- 不用
()时，$matches是一维数组（$matches[0]即结果） - 如果正则里写了
([a-z]+)@，那$matches[1]就是所有用户名部分 - 性能上，
preg_match_all比循环调用preg_match快得多，PHP 内部做了优化
PREG_SET_ORDER 和 PREG_PATTERN_ORDER 的区别
这两个常被忽略的 flag 决定了 $matches 的结构，直接影响你怎么取数据。
-
PREG_PATTERN_ORDER（默认）：按“匹配维度”组织，$matches[0]是全部完整匹配，$matches[1]是全部第一个捕获组 -
PREG_SET_ORDER：按“每次匹配”组织，$matches[0]是第一次匹配的全部组（[0]完整、[1]第一组…），更接近直觉
示例对比：
// 文本：'id:123 name:abc; id:456 name:def'
preg_match_all('/id:(\d+) name:(\w+)/', $text, $m, PREG_PATTERN_ORDER);
// $m[0] = ['id:123 name:abc', 'id:456 name:def']
// $m[1] = ['123', '456'] ← 所有 id
preg_match_all('/id:(\d+) name:(\w+)/', $text, $m, PREG_SET_ORDER);
// $m[0] = ['id:123 name:abc', '123', 'abc']
// $m[1] = ['id:456 name:def', '456', 'def']
空匹配、重叠匹配与性能提醒
preg_match_all 默认跳过空匹配（比如 /a*/ 在 'x' 上会停在开头但不记录），也不支持重叠匹配（/aa/ 在 'aaa' 中只匹配一次，而非两次）。这些不是 bug，是 PCRE 引擎行为。
- 需要重叠匹配？得手动挪偏移量，用
preg_match+substr循环 - 大量文本 + 复杂正则容易触发回溯爆炸，加
u或s修饰符本身不慢，但错误的量词嵌套（如(a+)+）会让性能断崖下跌 - 如果只是简单分隔（如按逗号拆字符串），别硬套
preg_match_all，explode或str_getcsv更快更安全
真正难的从来不是语法，而是想清楚你要的是“所有匹配片段”，还是“每个匹配里特定字段”，以及是否允许跨行、含 Unicode、有嵌套结构——这些决定了修饰符、括号层级和后续怎么遍历 $matches。
