DOM深度超3层会拖慢布局计算，因每增一层需多做样式继承、属性回溯和布局上下文创建；实测显示深度超3层后layout耗时非线性上升，6层以上getComputedStyle()耗时可能翻倍并触发强制同步布局。
DOM深度超3层会拖慢布局计算
DOM深度每增加一层，浏览器就要多做一次样式继承、属性回溯和布局上下文创建。实测显示，深度超过3层后，layout耗时开始非线性上升；到6层以上，getComputedStyle()调用耗时可能翻倍，还容易触发强制同步布局（forced synchronous layout）。这不是“看起来慢”，而是DevTools里Performance面板能直接抓到的Layout阶段飙升。
- 常见高危结构：
- 别用嵌套div实现间距或对齐——
margin、gap、flex或grid一行CSS就能替代三层DOM - SSR模板生成的空wrapper（如
用CSS接管视觉层级，而不是堆DOM
很多所谓“结构需要”的嵌套，其实是把本该由CSS表达的视觉关系，错误地交给了HTML。压平DOM不是删标签，而是把层级逻辑从DOM树转移到CSS规则中。
- 图标+文字组合：改用
，而非三层div包裹 - 分隔线：用
::before或border-bottom，别加 - 卡片容器：合并
card-inner/card-body/card-content为单层，靠padding和grid控制内部空间 - 表单控件组：用
或带class的语义化包裹，避免无意义div套娃
验证是否真压平了，别只看源码
源码看着扁平，不等于渲染树真的浅。某些框架注入的不可见wrapper、服务端预渲染插入的空节点，都会悄悄抬高真实深度。
- Chrome DevTools → Elements面板 → 右键任意节点 →
Show DOM properties→ 查看depth值，超过6就要动手 - Performance面板录制首屏加载，重点关注
Layout阶段耗时是否随DOM深度下降明显回落 - 运行
document.querySelectorAll('*').length检查总节点数，但更关键的是用document.querySelector('body').children[0].children[0]…手动探查嵌套层数 - 注意：即使用了
transform或will-change，深层结构仍会拖慢合成前的矩阵计算和图层判定
批量插入时DOM膨胀最隐蔽
循环appendChild()插入100个项，表面看只是多了100个节点，实际会触发100次重排计算。更危险的是v-html或innerHTML直接塞入未清洗的服务端HTML——空格、注释、冗余class全变成真实节点。
- 大量节点插入优先用
DocumentFragment缓存，最后一次性挂载 - 服务端返回HTML字符串时，先用
DOMPurify.sanitize()过滤，再用insertAdjacentHTML()插入 - 滚动加载列表必须上虚拟滚动，保持真实DOM节点数稳定在50–100以内，否则
offsetHeight等读操作延迟会陡增 - 开发期加CI检测：用
jest或cypress跑document.querySelectorAll('*').length > 2000断言，防节点失控
真正卡住渲染的，往往不是你写了多少标签，而是这些标签堆叠了多少层。压平不是为了代码好看，是让浏览器少走几层父链查找、少建几个无效布局上下文——这些动作在主线程上发生，且无法被JS异步绕过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
