浏览器HTML解析器采用状态机非递归实现，1000层嵌套div在解析阶段不会栈溢出；真正风险来自JS层递归遍历、querySelectorAll隐式递归或布局引擎未控深递归。
浏览器解析器根本不递归处理嵌套
HTML 解析器不会因为写了 10 层 <div> 就栈溢出——Chrome（Blink）、Firefox（Gecko）都用状态机实现，非递归。你写 <div><div><div>...</div></div></div> 到 1000 层，解析阶段照样秒过。
真正出问题的环节在解析之后：
-
querySelectorAll('*')在极端嵌套下，旧版 WebKit 内部匹配逻辑可能隐式递归 -
element.innerHTML = hugeString触发重排时，Blink 的 LayoutTree 构建在某些路径下存在未控深递归（2025 年 Safari 17.4 曾报告） - 你自己写的
walk(node)递归遍历没加深度限制，node.childNodes.forEach(walk)直接爆栈
嵌套过深导致布局性能衰减怎么验证
不是看源码缩进，而是查浏览器生成的真实 DOM 树：
- DevTools → Elements 面板 → 右键节点 → “Show DOM properties” → 查
node.depth，≥6 就该警觉 - 切换到 Layers 面板，如果看到大量零碎、重叠的小方块，说明合成层碎片化，大概率是
position: relative+ 深层嵌套共同导致 - 在 Console 运行
document.querySelector('body').children[0].children.length，返回值远大于视觉区块数（比如首页只该有 3 块却返回 8），说明冗余包裹严重
实测：5 层以上嵌套在低端安卓机上会让 FCP 延迟 20–50ms；超 6 层时样式计算路径显著变长，匹配结束标签的成本指数上升。
立即学习“前端免费学习笔记（深入）”；
嵌套 <table> 实际不嵌套，而是被“踢出”
写 <td><table><tr><td>inner</td></tr></table></td>，浏览器不会把它当子表格渲染——它会自动闭合当前 <td> 和外层 <tr>、<table>，再新建一个独立表格上下文。
结果 DOM 结构变成两个并列的 <table>，子表脱离单元格，飘到文档顶部或底部。
- 正确做法：子表格必须完整写在单个
<td>或<th>内容体中 - 子表也必须带
<thead>和<tbody>，否则浏览器补全位置不可控，table.tBodies[0].rows可能读不到数据 - 边框错乱？只设
border没用，必须统一加border-collapse: collapse
<label> 嵌套 <input> 触发两次 click 怎么办
这不是 bug，是 W3C 规定的语义激活机制：点击 <label> 先触发自身 click，再由浏览器自动调 input.click()，后者又冒泡一次。
- 首选解法：
<input id="x"><label for="x">文本</label>，平级 +for关联，彻底避开嵌套 - 必须嵌套时，在
<input>上加onclick="event.stopPropagation()"—— 写在<label>上无效，因为第一次冒泡已经发生 - 别用
return false，它会阻止默认行为（比如取消勾选），破坏可访问性 - 内联写法
onclick="handleClick()"若函数没声明参数，event是undefined，stopPropagation()必然失效
深层嵌套本身不危险，危险的是嵌套 + 特定 JS 行为组合；最常被忽略的是：DOM 树结构正常 ≠ 渲染和交互表现正常 —— 从 node.depth 到 Layers 面板，得靠工具实测，不能靠肉眼数 div。
