php 中用正则匹配嵌套 html 标签不可靠，因 pcre 的 nfa 引擎易触发灾难性回溯，导致 backtrack_limit 超限或内存耗尽；正确做法是使用 domdocument 等解析器而非正则。
PHP 里用正则匹配嵌套 HTML 标签（比如 <div>...<div>...</div>...</div>）本质上不可靠，强行写会导致 pcre.backtrack_limit 超限、卡死或 Fatal error: Allowed memory size exhausted —— 不是配置调大就能解决，而是模式本身在 PCRE 下就容易触发灾难性回溯。
为什么 preg_match 处理嵌套标签必踩回溯坑
PCRE 是 NFA 引擎，遇到类似 <div>.*<div>.*</div>.*</div> 这种结构时，.* 会先吞掉整段文本，再逐个字符回退尝试匹配闭合标签；一旦嵌套层数增加或内容含干扰字符（如注释、JS 字符串里的 ），回溯次数呈指数爆炸。哪怕字符串只有几百字节，(?:<div>|</div>|[^ 这类“模拟栈”的写法也会迅速撞上默认的 <code>1000000 回溯上限。
常见错误现象：preg_match() 返回 false 但 error_get_last() 显示 PREG_BACKTRACK_LIMIT_ERROR；或者脚本直接内存耗尽中断。
- 嵌套越深，回溯路径越多 —— 每层额外引入至少 O(2ⁿ) 尝试组合
-
.*?在嵌套场景下几乎没用，非贪婪只控制单层，不阻止跨层回溯 - 原子组
(?>...)或占有量词++只能局部抑制，无法解决整体结构性回溯
真正能跑通的替代方案：别用正则解析嵌套结构
用正则“匹配嵌套标签”属于误用场景。PCRE 不支持递归匹配（除非启用 PCRE_EXTENDED + (?R)，但 PHP 的 preg_*() 不支持该特性），所谓“能用”都是对简单、可控、无干扰内容的侥幸。
实操建议：
- 用
DOMDocument解析 HTML：它原生处理嵌套、自动修复 malformed 结构，且性能稳定 ——$dom = new DOMDocument(); @$dom->loadHTML($html); - 若只需提取某一层级（如所有最外层
<div>），先用 <code>strpos()+substr()扫描起始/结束位置，避免全量正则 - 若必须用正则做轻量预处理（如剥离注释、提取 script 内容），确保目标无嵌套 —— 例如
/<script>]*>(.*?)<\/script>/is</script>仅用于单层 script 块 - 查当前值：
var_dump(ini_get('pcre.backtrack_limit'));（默认1000000） - 设为稍高但可控的值：
ini_set('pcre.backtrack_limit', '2000000'); - 同步调
pcre.recursion_limit（默认也是1000000），否则可能卡在递归深度而非回溯数 - 注意：这两个设置对 CLI 和 Web SAPI 行为一致，但重启后失效；写入
php.ini会影响整个 PHP 实例
如果硬要调参，pcre.backtrack_limit 和 pcre.recursion_limit 怎么设才安全
调高这两个值只是延迟报错，不能根治问题。而且它们是全局 ini 设置，影响所有正则，不是 per-pattern 控制项。
可临时调整（仅限调试，生产环境慎用）：
真正关键的不是数值，而是——只要你的正则里出现 .* 或 .*? 匹配跨标签内容，就等于把回溯风险交给了输入长度。哪怕设成 10000000，一段构造过的 a{1000} 字符串仍能让它崩。
嵌套结构的本质是上下文相关语言，而正则表达式描述的是正则语言。这个鸿沟没法靠调参数或换写法抹平。该用解析器的时候，就别省那几行代码。
