php 8 引入 pcre2 后，`preg_match` 在处理大文本时可能比 `strpos` 更快，这源于 pcre2 的 jit 编译、高度优化的字符串搜索算法（如优化的 boyer-moore 变体）和向量化指令支持，而 `strpos` 仍基于较朴素的 sunday 算法且无现代 cpu 特性利用。
在 PHP 性能演进中，一个反直觉但已被实证的现象是：对较大文本（如 30KB+），preg_match（尤其是 preg_match_all）在 PHP 8.1+ 中可能显著快于 strpos——这与传统认知“正则一定更慢”相悖。根本原因在于底层引擎的代际差异：
✅ PCRE2：现代正则引擎的性能飞跃
PHP 7.3 起默认启用 PCRE2（取代 PCRE1），并在 PHP 8.0+ 深度集成 JIT 编译器。其优势包括：
- JIT 编译加速：正则模式首次编译后生成原生机器码，避免解释开销；
- 智能算法选择：对字面量模式（如 /\[SOMEMACRO\]/）自动退化为高度优化的子串搜索（类似改进版 Boyer-Moore-Horspool），支持 SIMD 指令并行扫描；
- 内存访问优化：预计算跳转表、缓存友好型遍历，对长文本吞吐率极高。
⚠️ strpos：简单但未持续演进
尽管语义简单，strpos 在 PHP 8 中并未同步获得底层算法升级：
- 小字符串（< 256B）使用 memchr 快速定位；
- 大字符串默认采用 Sunday 算法，虽平均性能尚可，但缺乏向量化、分支预测优化，且无法利用现代 CPU 的宽寄存器并行处理；
- 无 JIT 或模式预编译机制，每次调用均为纯解释执行。
? 实测验证关键点
你提供的基准测试揭示了典型拐点：
立即学习“PHP免费学习笔记（深入）”；
// 示例：PHP 8.1.2 下 30KB 文本（100 万次调用） echo "strpos: 9.97s\n"; // 朴素算法累积开销显著 echo "preg_match_all: 1.24s\n"; // PCRE2 JIT + 优化搜索胜出
而小文本（200B）时 strpos 仍更快（0.0358s vs 0.0867s），印证了 “PCRE2 启动开销 > 算法收益” 的临界点现象——即模式编译与上下文初始化成本在短任务中成为瓶颈。
? 实践建议
- 大文本精确字面匹配：优先用 preg_match('/\Q[SOMEMACRO]\E/', $text)（\Q...\E 自动转义，避免正则解析开销）；
- 小文本或高频单次查找：坚持 strpos，简洁可靠；
- 避免误区：不要因“正则慢”教条拒绝 preg_*——PCRE2 已使其成为高性能文本处理的合理选项；
- 统一基准：测试时固定 PHP 版本、Opcache 开启状态、禁用 Xdebug，避免干扰。
? 总结：性能优劣取决于场景而非函数名。PHP 8 的 PCRE2 是经过工业级打磨的文本处理引擎，而 strpos 本质是 C 标准库的轻量封装。当数据规模跨越阈值，专业引擎的深度优化必然超越通用函数——这正是现代 PHP 高性能的底层逻辑之一。
