浏览器渲染树深度超20层会明显拖慢layout阶段，实测≥21层时layout耗时跳升40%以上，尤其在低端Android WebView中更剧烈；需通过Chrome DevTools Elements面板右键节点“Reveal in Layers panel”或对比scrollHeight定位，纯容器堆叠是主要隐患，shadowRoot无法降低深度计数但可隔离样式与事件。
浏览器渲染树深度超 20 层会明显拖慢 layout 阶段
Chrome 和 Safari 的渲染管线中，DOM 树过深会直接放大 layout（重排）耗时，尤其在频繁更新的动态区域（如列表滚动、表单联动）。实测发现：当嵌套层级 ≥ 21（即从 算起第 21 层），layout 平均耗时跳升 40% 以上，且该现象在低端 Android WebView 中更剧烈。
这不是理论限制，而是真实性能拐点。浏览器内部用递归遍历构建渲染树，深度过大触发栈深度保护或缓存失效，不是“建议避免”，而是“必须截断”。
-
<div><div><div>...</div></div></div>这类纯容器堆叠是最大隐患，尤其被 JS 动态生成时不易察觉 - 框架如 React/Vue 默认不设嵌套防护，
jsx或template深度由开发者控制，编译期无警告 - 检查方法：打开 Chrome DevTools → Elements → 右键节点 → “Reveal in Layers panel”，看右侧渲染层树深度；或运行
document.body.scrollHeight对比document.documentElement.scrollHeight异常差值（可能暗示隐式嵌套膨胀）
shadowRoot 不缓解 DOM 深度问题，但可隔离样式与事件传播
有人误以为用 shadowRoot 把深层结构包进自定义元素就能“重置”深度计数——实际无效。Shadow DOM 内部仍计入整体渲染树深度，layout 阶段照常遍历，只是样式和事件作用域被隔离。
真正价值在于：它让深度失控的子模块不影响父组件的 CSS 选择器匹配效率和事件冒泡路径长度。
- 使用
attachShadow({mode: 'closed'})后，父级querySelector查不到 shadow 内节点，但layout时间仍叠加计算 - 若嵌套发生在 shadow 内（比如自定义组件自己又嵌了 15 层），问题照旧；需在 shadow 内部也执行深度控制
- 适合场景：将第三方 widget（如评论框、广告位）封装进 shadow，防止其 DOM 污染主树结构，但不能替代扁平化设计
用 slot 替代多层 wrapper 是最轻量的扁平化手段
多数深层嵌套源于“为了样式/布局加壳”，比如为实现圆角+阴影+内边距，套三层 <div class="card">
<div class="card-body"><div class="card-content">...></div></div>。用 <code><slot></slot> 直接透传内容，配合现代 CSS（contain: layout、isolation: isolate）即可解耦。
关键不是删标签，而是让标签承担语义而非仅装饰职责。
- 把
<my-card><p>Hello</p></my-card>的内部实现从嵌套 div 改为：<div class="card"><slot></slot></div> - 配合
.card { contain: layout style paint; }，浏览器会把该元素作为独立渲染边界，大幅降低 layout 影响范围 - 注意：IE 不支持
slot，如需兼容，用data-*属性 + JS 手动迁移节点，比维持 10 层 div 更可控
用 document.createDocumentFragment() 批量插入时仍要检查最终深度
很多人以为用 DocumentFragment 就能规避深度问题——它只优化插入性能（减少重排次数），不改变最终 DOM 结构深度。如果 fragment 里塞了 25 层嵌套再 append 到 body，渲染树照样是 25 层。
真正有效的做法是在 fragment 构建阶段就做深度校验，而不是等插入后。
- 写个简易检查函数：
function getDepth(node) { return node.parentNode ? 1 + getDepth(node.parentNode) : 0; }，在 fragment.appendChild 前调用 - 对动态生成场景（如表格行渲染），用 CSS Grid / Flex 替代嵌套 div 布局，把“结构深度”转为“样式计算复杂度”，后者浏览器优化更成熟
- 警惕模板字符串拼接：
`<div><div><div>${data}</div></div></div>`很难静态分析深度，应改用 createElement + appendChild 链式调用，便于插桩检测
深度控制不是删代码，是把“靠嵌套实现功能”的惯性，转向用 CSS 能力、Web Components 语义、渲染边界隔离来达成同样效果。最容易被忽略的点是：工具链（Prettier、ESLint）默认不检查 DOM 深度，必须在 CI 中接入自定义 Linter 规则或 Puppeteer 性能巡检脚本，否则上线后才发现，已经晚了。
