PHP正则性能差主因是写法不当：应优先用preg_match而非preg_match_all，避免.*回溯，禁用隐式回调，合理启用JIT，且重复模式需预编译。
PHP正则表达式慢，八成不是引擎不行，而是模式写法触发了回溯爆炸、函数用错、或 JIT 白开了。关键得看怎么写、怎么调、怎么配。
preg_match 比 preg_match_all 快得多
只要确认「存在一个匹配就够了」，就别用 preg_match_all——它强制扫描全文、收集全部结果，开销翻倍。比如校验邮箱、检测关键词、判断是否含某标签，preg_match 足够且更快。
- 匹配失败时，
preg_match通常在首次不匹配处就退出；preg_match_all却会继续尝试直到字符串末尾 - 若真需要所有匹配，但已知最多只有一两个，可先用
preg_match判断存在性，再按需调用preg_match_all - 注意：两者都不缓存编译结果，重复使用同一模式时，应提前赋值给变量（如
$pattern = '/^\d{3}-\d{2}-\d{4}$/';），避免每次解析
.* 是性能杀手，用 [^x]* 替代
像 <script.>.*?</script.> 这类写法看着简洁，实际极易引发大量回溯。点号 . 匹配“除换行外任意字符”，引擎无法预判边界，只能反复试探。
- 提取引号内内容？用
"([^"]*)"，不是".*?" - 匹配 HTML 标签属性值？用
value="([^"]*)"，而非value="(.*?)" - 若必须跨行，加
s修饰符，但优先考虑是否真需跨行——多数场景用[^\n"]*更稳 - 遇到嵌套结构（如括号、标签嵌套），正则本身就不适合，该上 DOM 或递归解析器
pcre.jit=1 不等于一定快
启用 JIT 编译（php -i | grep pcre 确认含 PCRE is compiled with JIT support，且 php.ini 中 pcre.jit=1）能加速中长正则，但对短小高频模式反而拖累。
立即学习“PHP免费学习笔记（深入）”；
- JIT 编译后每个正则约占 16KB 内存，FPM 下每个 worker 进程需独立触发一次，冷启动时无收益
- 子进程（如
pcntl_fork()）不继承 JIT 缓存，fork 后首次匹配仍要编译 - 简单替换如
preg_replace('/\s+/', ' ', $str)，JIT 带来的编译+内存开销可能超过解释执行成本 - 建议：只对长度 > 20 字符、重复调用 ≥ 100 次/秒的正则开启 JIT，并监控内存增长
preg_replace_callback 是隐式性能陷阱
回调函数看似灵活，实则是 PHP 用户态调用，每次匹配都触发上下文切换。更危险的是，回调里再调用正则（比如日志里又跑一次 preg_match），极易栈溢出。
- 能用
$replacement参数完成的，绝不进回调：比如把preg_replace_callback('/(\d{4})-(\d{2})-(\d{2})/', function($m) { return "$m[3]/$m[2]/$m[1]"; }, $s)改成preg_replace('/(\d{4})-(\d{2})-(\d{2})/', '$3/$2/$1', $s) - 回调中禁止再调用任何正则函数，包括
preg_quote（它内部也走 PCRE） - 若逻辑复杂必须用回调，请先用
strpos预筛：只有含关键词才进回调，避免无效触发
真正卡顿的点，往往藏在「以为安全」的地方：比如循环里拼接变量生成正则、用 .* 处理用户输入、或在 fork 后反复编译同一模式。优化不是堆配置，而是让每条正则都可预测、可测量、可放弃。
