dom树深度超6层会显著拖慢样式计算和重排，因浏览器需向上递归遍历祖先匹配css选择器，深度每+1耗时增约12%，深度12时低端机单次getcomputedstyle()卡顿超80ms；iframe嵌套≥3层会被chrome/safari主动挂起渲染，表格单元格内嵌套div易触发同步布局。
DOM树深度超6层会显著拖慢样式计算和重排
浏览器计算每个元素的最终样式时，必须从该节点一路向上遍历所有祖先，匹配CSS选择器。深度每+1，匹配路径就多一次递归查找——body > div > div > div > .item这种写法在深度8的树里，比深度4时getComputedStyle()耗时翻倍。低端安卓机上，深度达12时单次调用可能卡顿80ms以上。
常见错误现象：
-
querySelectorAll('.item')查100个节点时，DOM深度每+1，总耗时平均+12% - 在深度10的DOM里循环读取
offsetTop或clientWidth，会强制触发100次同步布局，而非1次 -
visibility: hidden不解决根本问题：深层DOM下它仍保留布局计算，display: none才是真隐藏
Chrome/Safari对iframe嵌套≥3层主动挂起渲染
这不是卡顿，是浏览器策略性冻结。Chrome 124+检测到<iframe><iframe><iframe></iframe></iframe></iframe>结构后，直接丢弃子帧绘制请求，Layers面板里看不到合成层，IntersectionObserver不触发，getBoundingClientRect()返回{x: 0, y: 0}等默认值，且Console无报错。
实操建议：
- 别依赖Network面板判断——所有
src都显示200，但渲染管线已静默跳过 - 在Console运行检查脚本：
(function checkIframeDepth(node, depth = 0) { if(node.tagName === 'IFRAME') { console.log(`深度 ${depth}:`, node.src || '(no src)'); depth++; } for(let child of node.children) { checkIframeDepth(child, depth); } })(document.body); - 唯一有效解法是结构降级：用
<object></object>替代第三层iframe，或改用Web Component封装子内容
表格单元格里嵌套极易触发同步Layout
<td>内部样式计算本就比普通块级元素重，再套一层<code><div>，尤其当该<code><div>含<code>display: flex或position: relative时，浏览器必须在每次重排前重新计算整行表格的列宽与布局关系。
错误写法：<td><div class="cell-content"><p>文本</p></div></td>
正确写法：直接给<td>加类或内联样式，或用<code><figure></figure>+<figcaption></figcaption>替代无意义包裹
若必须用容器，优先选<span></span>（行内容器），避免触发块级布局重算
特别注意：<td>的内容模型只允许 phrasing content（如<code><span></span>、<em></em>、文本），<div>属于flow content，禁止直接子元素。浏览器实际解析结果是：<code><td><div>xxx</div></td> → 拆成<td></td>
<div>xxx</div>
<td></td>，导致空<td>节点增加、表格布局上下文重建、行高计算异常。
<h3>怎么一眼看出你的HTML嵌套过深</h3>
<p>别数源码缩进，看浏览器实际生成的DOM树：</p>
<ul>
<li>Chrome DevTools → Elements 面板右键任意节点 → <code>Show DOM properties 查看depth值，超过6就要重构
用<section></section>、<main></main>、<article></article>等语义标签替代三层以上<div class="wrapper">堆叠，语义标签本身不增加解析开销
<li>特别注意 SSR 或框架生成的 HTML，比如 Next.js 输出的 <code><div data-reactroot> 外层常被无意加深两层，需手动检查父容器
<p>深层嵌套常伴随合成层碎片化，放大重排开销：深层<code>div堆叠 + position: relative + overflow: hidden 或 transform滥用，会让浏览器为每一层创建独立合成层。DevTools的Layers面板里出现大量小尺寸、重叠的方块，就是典型信号——这些层之间无法合并，每次滚动或动画都要单独上传纹理、单独合成。
<td>内部样式计算本就比普通块级元素重，再套一层<code><div>，尤其当该<code><div>含<code>display: flex或position: relative时，浏览器必须在每次重排前重新计算整行表格的列宽与布局关系。
错误写法：<td><div class="cell-content"><p>文本</p></div></td>
正确写法：直接给<td>加类或内联样式，或用<code><figure></figure>+<figcaption></figcaption>替代无意义包裹
若必须用容器，优先选<span></span>（行内容器），避免触发块级布局重算
特别注意：<td>的内容模型只允许 phrasing content（如<code><span></span>、<em></em>、文本），<div>属于flow content，禁止直接子元素。浏览器实际解析结果是：<code><td><div>xxx</div></td> → 拆成<td></td>
<div>xxx</div>
<td></td>，导致空<td>节点增加、表格布局上下文重建、行高计算异常。
<h3>怎么一眼看出你的HTML嵌套过深</h3>
<p>别数源码缩进，看浏览器实际生成的DOM树：</p>
<ul>
<li>Chrome DevTools → Elements 面板右键任意节点 → <code>Show DOM properties 查看depth值，超过6就要重构
<section></section>、<main></main>、<article></article>等语义标签替代三层以上<div class="wrapper">堆叠，语义标签本身不增加解析开销
<li>特别注意 SSR 或框架生成的 HTML，比如 Next.js 输出的 <code><div data-reactroot> 外层常被无意加深两层，需手动检查父容器
<p>深层嵌套常伴随合成层碎片化，放大重排开销：深层<code>div堆叠 + position: relative + overflow: hidden 或 transform滥用，会让浏览器为每一层创建独立合成层。DevTools的Layers面板里出现大量小尺寸、重叠的方块，就是典型信号——这些层之间无法合并，每次滚动或动画都要单独上传纹理、单独合成。
