preg_match返回false不等于正则写错，须立即调用preg_last_error()和preg_last_error_message()诊断，常见原因包括回溯超限、JIT栈溢出或UTF-8偏移非法。
preg_match 返回 false 但正则没错？先查 preg_last_error()
PHP 8.2 中 preg_match() 突然返回 false，不一定是正则写错了——大概率是触发了 PCRE 的回溯限制。必须在调用后**立刻**检查错误码：preg_last_error() 和 preg_last_error_message()（PHP 7.2+ 支持）。常见返回值包括：
-
PREG_BACKTRACK_LIMIT_ERROR：回溯次数超过ini_get('pcre.backtrack_limit')（默认 100 万） -
PREG_JIT_STACKLIMIT_ERROR：JIT 执行栈溢出，匹配中断并降级为解释执行 -
PREG_BAD_UTF8_OFFSET_ERROR：带u修饰符时，$offset指向 UTF-8 多字节字符中间字节
调大 pcre.backtrack_limit 的安全方式
直接设成 -1（无限制）风险极高，容易被恶意输入触发回溯炸弹（ReDoS），导致 CPU 100% 或服务不可用。推荐按需设置、分场景控制：
- 对可信、可控的长文本（如日志解析），临时提高：
ini_set('pcre.backtrack_limit', '5000000'); - 对用户输入或爬虫采集内容，优先优化正则本身（避免
.*嵌套、用原子组(?>...)或占有量词++） - 若必须全局放宽，改
php.ini而非运行时ini_set()，并配合memory_limit限制：ini_set('memory_limit', '128M'); - 注意：PHP 8.2 默认启用 JIT（
pcre.jit=1），但 JIT 对复杂长匹配反而更易失败；可临时禁用：ini_set('pcre.jit', '0');
pcre.recursion_limit 别乱调高
这个值控制 PCRE 内部递归深度，默认 10 万。它和栈空间强相关——设太高不会报错，但可能直接让 PHP 进程因堆栈溢出而崩溃（SIGSEGV），尤其在 Apache prefork 或 CLI 场景下。
- 不要设成
-1或超 200000 - 多数长文本匹配场景，保持默认或略增到
150000即可 - 与
pcre.backtrack_limit不同，它不能通过ini_set()在 Web SAPI 中动态修改（仅 CLI 可），所以务必提前在php.ini中确认
真正棘手的是 JIT + 长文本 + UTF-8 的组合
PHP 8.2 默认开启 JIT，但 JIT 编译器对超长 UTF-8 字符串（尤其含大量代理对或混合编码）非常敏感。典型现象是：Warning: preg_match(): JIT compilation failed: no more memory，此时匹配会自动降级，但性能暴跌且行为难预测。
立即学习“PHP免费学习笔记（深入）”；
- 优先尝试关闭 JIT：
ini_set('pcre.jit', '0');，再测是否稳定 - 确保输入字符串是合法 UTF-8：
mb_check_encoding($subject, 'UTF-8')，非法字节会加剧 JIT 失败 - 若必须用 JIT，避免在
u修饰符下对 >1MB 的字符串做贪婪匹配；拆分处理或改用mb_*函数预处理
/(a+)+b/ 在 10KB 字符串里就能耗尽回溯配额。调试时永远先看 preg_last_error()，而不是反复改正则。 
