优先用strpos()判断子串存在，因其无正则编译开销、执行更快、更安全；仅当需模糊/模式匹配时才用preg_match()。
preg_match 和 strpos 哪个更适合判断子串存在
如果只是检查某个固定字符串是否出现，strpos() 几乎总是更快、更安全的选择。它不启动正则引擎，无编译开销，也不受 PCRE 回溯或修饰符影响。
常见错误是用 preg_match('/abc/', $str) 替代 strpos($str, 'abc') !== false —— 尤其在循环里，性能差距会随数据量放大。
- 当子串含正则元字符（如
.、*、+）且你本意是字面匹配时，preg_match会意外匹配错误内容；strpos则严格按字节比对 -
strpos返回位置索引，方便后续切片；preg_match需额外传$matches参数才能取到位置，还默认只找第一个 - 若需忽略大小写，
stripos()比preg_match('/abc/i', $str)更轻量
str_replace 和 preg_replace 在替换场景下的取舍
简单字面替换一律优先用 str_replace()：它不解析正则语法，不会因误写 \ 或 . 导致崩溃或逻辑错乱。
只有当你需要「按模式替换」时才启用 preg_replace()，比如统一处理所有 URL、提取带编号的标签内容、或根据上下文动态构造替换值。
立即学习“PHP免费学习笔记（深入）”；
-
str_replace(['a', 'b'], ['x', 'y'], $str)支持批量字面替换；preg_replace的数组参数是「模式-替换」对，不能混用 - 使用
preg_replace时，若模式中含/（如匹配路径），建议换用#或~作定界符，避免大量\/转义 -
preg_replace默认不支持 UTF-8 安全的多字节字符边界（如中文标点），必须加u修饰符，否则可能截断字符
什么时候必须用 preg_match_all 而不是 explode + strpos
当你需要提取「结构化片段」而非简单分割时，preg_match_all() 不可替代。例如从 HTML 片段中抽取出所有 <a href="...">...</a> 的链接文本和地址，或从日志行中捕获时间戳、状态码、路径三元组。
explode() 和嵌套 strpos() 在这类场景下极易出错：无法处理嵌套结构、忽略属性顺序、对空格/换行敏感、难以应对缺失字段。
-
preg_match_all('/<a>]*href=["\']([^"\']+)["\'][^>]*>([^/iu', $html, $matches)</a>可一次性分离链接地址与文本，$matches[1]是所有href，$matches[2]是对应文本 - 注意
PREG_SET_ORDER和PREG_PATTERN_ORDER对结果组织方式的影响：前者按「每次匹配」分组，后者按「每个捕获组」分组，选错会导致遍历逻辑混乱 - 避免写
.*匹配中间内容——它贪婪且易引发回溯爆炸；改用[^ 或非贪婪 <code>.*?（并确认u修饰符已启用）
PCRE 编译缓存和模式复用的实际影响
PHP 内部对 PCRE 模式有 per-thread 缓存（上限 4096 条），但前提是模式字符串完全一致。这意味着变量拼接、动态生成的正则（如 '/' . $keyword . '/'）每次都会重新编译，失去缓存收益。
容易被忽略的是：即使模式字面相同，不同修饰符（如 /i vs /iu）也被视为不同条目，各自占用缓存槽位。
- 高频调用的正则应定义为常量或静态变量，避免重复构造字符串
- 不要在循环内拼接正则模式，尤其当
$keyword来自用户输入时，既慢又可能引入注入风险（如$keyword = '.*';） - 用
preg_last_error()检查是否因模式过长或嵌套过深导致编译失败，而不是静默返回false
