DOM嵌套过深会拖慢样式计算，因CSS选择器从右往左匹配，层级越深回溯路径越长，易触发强制同步布局；应控制在3层内、避免空节点、优化选择器右侧唯一性并缓存查询结果。
为什么DOM嵌套过深会拖慢样式计算
浏览器解析CSS选择器时是从右往左匹配的，比如 .list-item > .content span.title，它先找所有 span.title，再向上逐层验证父级是否符合 .content 和 .list-item > .content。DOM层级越深，每次向上回溯的路径就越长，尤其当页面有成百上千个匹配节点时，这个开销会指数级放大。
更实际的问题是：嵌套超过6层的 <div> 容易触发浏览器强制同步布局（forced synchronous layout），哪怕只是读取 <code>offsetHeight，也可能让重排提前发生——这在滚动或动画中极易卡顿。
- 用
display: flex或display: grid替代多层<div> 包裹实现布局，把结构压到 3 层以内<li>检查 DevTools 的 “Layers” 面板，看是否有意外的合成层分裂，那往往源于深层嵌套+will-change/transform滥用</li> <li>避免在循环中读写布局信息：<code>clientWidth、getBoundingClientRect()、offsetTop等，它们会强制刷新样式树 - 删除仅用于清除浮动的
<div style="clear:both">，改用 <code>overflow: hidden或::after { content:""; display:table; clear:both; } - Vue/React 中慎用
v-html或dangerouslySetInnerHTML渲染整段HTML，它可能带入深层嵌套；优先用组件化结构控制输出深度 - 服务端渲染（SSR）时避免生成带空属性的节点，如
<div data-v-xxx="">，这些仍计入DOM树并参与样式计算<h3>CSS选择器怎么写才不容易触发深度遍历</h3> <p>关键不是“写得短”，而是“右边够唯一”。<code>div p span比.user-name慢得多，因为前者要遍历全部span再逐层验证祖先，后者直接哈希查找。现代浏览器虽做了优化（比如对 ID 选择器跳过部分回溯），但无法绕过 DOM 树本身的遍历成本。所以真正有效的做法是减少右侧候选集数量，而不是纠结于“能不能用后代选择器”。
- 给高频使用的元素加唯一类名，如
<span class="msg__author"></span>，而不是依赖.message-container > .header > span - 避免通配符和属性选择器在关键路径上使用：
[data-id]、* + li会显著增加匹配耗时 - 慎用
:nth-child()，它需要浏览器计算每个兄弟节点的位置，DOM越深、兄弟越多，代价越高
document.querySelector 性能差，但问题不在它本身
document.querySelector慢，通常是因为你传进去的选择器太宽泛，或者调用时机不对。它本身只是入口，真正的瓶颈在样式匹配和DOM遍历阶段。比如在
scroll回调里反复执行document.querySelector('.sidebar .nav a.active')，每次都会从根开始查——而其实那个.active节点位置固定，缓存一次就够了。- 把高频查询结果缓存为变量，不要在循环或事件回调里重复调用
querySelector - 用
element.querySelector代替document.querySelector，限制搜索范围，尤其是列表项内操作 - 如果只是想监听某类节点变化，用
MutationObserver替代轮询式查询，避免主动触发样式计算
真实瓶颈往往藏在你以为“只是读一下”的地方：一个没注意的
offsetTop，一次没缓存的querySelector，一段被v-html塞进来的深层嵌套HTML——它们叠加起来，比你写的某个复杂算法更早拖垮页面。 - 给高频使用的元素加唯一类名，如
如何识别和清理冗余的DOM层级
不是所有嵌套都该删，但很多是历史遗留的“安全包裹”——比如为兼容旧IE加的 <div class="wrapper"><div class="inner">…</div></div>，现在完全没必要。真正影响性能的是不可见、无语义、无样式的空节点。
打开 Chrome DevTools → Elements 面板，按 Ctrl+F 搜索 <div></div> 或 class=""，再结合 “Coverage” 面板看哪些CSS规则实际未命中，就能快速定位无效包裹。
立即学习“前端免费学习笔记（深入）”；
