浏览器HTML解析器本身不递归处理嵌套，采用状态机非递归实现，1000层div不会在解析阶段引发栈溢出；真正风险来自JS层对DOM树的无防护递归遍历或特定API（如querySelectorAll、布局计算）在极端嵌套下的隐式递归调用。
HTML 解析器本身不会因标签嵌套过深直接触发 JVM 或浏览器引擎的 StackOverflowError；真正风险来自解析后生成的 DOM 树在 JS 层被递归遍历，或解析器内部使用了递归下降算法且未设深度限制。
浏览器 HTML 解析器是否用递归处理嵌套？
主流浏览器（Chrome/V8、Firefox/Gecko）的 HTML 解析器是基于状态机的非递归实现，不依赖函数调用栈来处理嵌套。这意味着写一个 1000 层 <div><div><div>...</div></div></div> 不会直接导致解析阶段栈溢出。
但要注意：解析完成后构建 DOM 树是另一件事——DOM 节点对象本身不占栈空间，但后续 JS 操作可能触发递归：
-
element.querySelectorAll('*')在极端嵌套下可能触发内部递归匹配逻辑（尤其旧版 WebKit） -
element.innerHTML = hugeString触发重排重绘时，样式计算或布局引擎（如 Blink 的 LayoutTree 构建）在某些路径下存在隐式递归 - 开发者写的
function walk(node) { node.childNodes.forEach(walk); }这类无深度防护的递归遍历，才是真实风险源
哪些 HTML 场景真会引发栈溢出？
不是嵌套本身，而是嵌套 + 特定 JS 行为组合才危险。常见触发点：
立即学习“前端免费学习笔记（深入）”；
- 使用
document.write()动态插入超深嵌套 HTML，且在onload或事件回调中反复调用——可能形成调用链叠加 - 自定义元素（Custom Elements）中，
connectedCallback内又同步创建同类型子元素，构成隐式递归（如父子都调customElements.define()） - 通过
DOMParser.parseFromString(html, 'text/html')解析恶意构造的嵌套 HTML，而该 HTML 中含大量<script>标签，每个都触发相同 handler —— 实际是事件循环+调用栈累积 - 使用
innerHTML设置内容后立即调用getBoundingClientRect()或getComputedStyle()，在极端嵌套下，某些浏览器布局代码路径存在未控深的递归计算（2025 年 Safari 17.4 曾报告类似问题）
如何验证当前页面是否存在栈溢出隐患？
别猜嵌套层数，看真实调用栈：
- 在 Chrome DevTools 的 Performance 面板录制操作，过滤
Recalculate Style或Layout事件，观察单次调用深度是否持续 > 100 帧 - 手动注入检测脚本：
function checkStackDepth() { try { return checkStackDepth() + 1; } catch (e) { return 0; } } console.log('Safe max depth:', checkStackDepth()); // 通常返回 10000~15000这能反映当前 JS 执行环境的可用栈空间，比硬编码阈值更准 - 若页面已崩溃，打开
chrome://crash或检查about:crashes，错误日志里出现Stack overflow in renderer process才是真问题，否则大概率是内存耗尽或 GC 压力大
真正要防的不是“100 层 div”，而是“10 层嵌套 + 每层绑一个 addEventListener + 每个 listener 又触发一次 querySelectorAll”。栈深度是调用链决定的，不是缩进决定的。
