preg_match_all 更适合提取多处内容，因为它会全局匹配字符串中所有符合模式的片段并一次性返回全部结果，而 preg_match 仅匹配首个即停止；默认按 PREG_PATTERN_ORDER 组织结果，$matches[0] 存所有完整匹配，$matches[1] 存第一个捕获组的所有值，支持 PREG_SET_ORDER 等标志灵活调整结构，配合 u 修饰符可正确处理中文与 emoji。
preg_match_all 为什么比 preg_match 更适合提取多处内容
因为 preg_match 只找第一个匹配就停，而复杂文本里往往有多个目标片段需要一并捕获。比如日志中重复出现的 {id:123} 或模板里的多个 {字*xxx@@yyy*字}，必须用 preg_match_all 才能拿到全部。
常见错误是误用 preg_match 循环调用——它不自动推进匹配位置，反复执行会卡在同一个地方。正确做法是直接用 preg_match_all 一次性拉取所有结果，再遍历处理。
- 默认返回格式是
PREG_PATTERN_ORDER：$matches[0] 是全部完整匹配，$matches[1] 是第一个捕获组的所有值 - 若要按“每次匹配为一行”组织数据，加
PREG_SET_ORDER标志 - 含中文或 emoji 时，务必加
u修饰符，否则\w、.会错判字节边界
替换时如何避免破坏原始标记结构
直接用 preg_replace 替换带边界的模式（如 {字*...*字}）容易把标记本身也吃掉，导致后续无法识别。更稳妥的做法是用捕获组把“内容”单独拎出来，再构造新字符串。
例如想把 {字*丛@@丛林法则*字} → 【丛】[丛林法则]，正则不能写成 /\{字\*(.*?)\*字\}/ 然后整个替换，而应：
立即学习“PHP免费学习笔记（深入）”；
- 用
/\{字\*([^@]+)@@(.*?)\*字\}/u捕获两段内容：$1是“丛”，$2是“丛林法则” - 替换字符串写成
'【$1】[$2]'，靠后向引用拼接，标记本身不参与替换 - 如果原始文本里
@可能出现在内容中，得改用非贪婪+排除式：/\{字\*([^@]+)@@((?:(?!@).)*)\*字\}/u
为什么 u 修饰符不是可选而是必须
PHP 的 PCRE 引擎默认按字节处理，遇到 UTF-8 编码的中文、日文或 emoji，一个字符占多个字节，.、\w、$ 都会失灵。比如 /^你好$/ 不加 u 会匹配失败，preg_match('/\w+/u', '测试') 才能正确返回汉字。
-
u开启后，\d仍只匹配 ASCII 数字，中文数字要用\p{Nd} -
\p{Han}匹配汉字，\p{Emoji}匹配 emoji，但需确认 PHP 版本 ≥7.4 且 PCRE 库支持 - 没加
u却处理中文时，preg_replace可能截断字节，输出乱码甚至 Warning
性能陷阱：贪婪匹配和回溯爆炸怎么防
写 .* 看似省事，但在长文本中极易引发灾难性回溯——尤其当模式末尾有固定字符串（如 .*abc）而实际文本不含 abc 时，引擎会尝试指数级组合。
- 优先用具体字符类替代
.：比如匹配“字母+下划线”，写[a-zA-Z_]而非. - 非贪婪是基础，但不够：用
(?:[^{]|{[^}]*})*这类“否定字符+例外”结构代替.*?更稳 - 锚定能大幅提速：开头加
^、结尾加$或\z，让引擎少做无谓试探 - 超长文本处理前，先用
mb_strlen($text) > 10000做粗筛，避免正则被拖死
真正复杂的嵌套结构（如 HTML 标签、括号配对），正则已力不从心，该上 DOMDocument 或递归解析器就别硬扛。
