深层DOM嵌套不直接慢，但会放大CSS选择器匹配成本，尤其错误使用BEM时导致渲染性能断崖下降；浏览器从右往左回溯匹配，每层嵌套增加父级验证开销，移动端可慢4倍以上。
深层DOM嵌套本身不直接“慢”，但会放大CSS选择器匹配成本，尤其当搭配错误的BEM用法时，渲染性能会断崖式下降。
浏览器CSS匹配是从右往左回溯的
比如写一个选择器 .page .main .card .card__title，浏览器不是从 .page 开始往下找，而是先定位所有 .card__title 元素，再逐个向上检查：它的父级是不是 .card？再往上是不是 .main？再往上是不是 .page？
每多一层嵌套，就多一次 DOM 节点遍历和父级验证。在移动端或低端 Android WebView 中，这种回溯可能比单类名 .card__title 慢 4 倍以上。
- DOM 节点越多、嵌套越深，匹配耗时越呈指数增长
- 伪类如
:hover或属性选择器如[data-status="loading"]会让最右端节点更难收敛，加剧回溯压力 - Chrome DevTools 的 Performance 面板里，“Recalculate Style”任务持续 >16ms，大概率就是这类选择器在拖后腿
BEM命名 ≠ BEM实践：HTML结构决定最终选择器深度
很多人写了 .card__title 类名，却仍在 HTML 里套了三层 <div class="card"><div class="card__body">
<h2 class="card__title">，然后 CSS 写成 <code>.card .card__body .card__title——这仍是三层嵌套，BEM 名字白写了。
立即学习“前端免费学习笔记（深入）”；
真正起作用的是最终生成的选择器是否为单类名，而不是你用了几个下划线。
- ✅ 正确：
<h2 class="card__title"></h2>+.card__title { } - ❌ 错误：
<div class="card"><div class="card__body"> <h2 class="card__title"> + <code>.card .card__body .card__title { } - ⚠️ 注意：Sass 中
.card { &__body { &__title { } } }会编译出非法的.card__body__title，BEM 明确禁止三层命名（块→元素→元素） - 用
display: flex或grid替代“安全包裹”类空<div>，把视觉结构压到 3 层以内 <li>删掉仅用于清除浮动的 <code><div style="clear:both">，改用 <code>::after伪元素 - Vue/React 中避免用
v-html或dangerouslySetInnerHTML渲染带深层嵌套的富文本片段
DOM层级过深还会触发强制同步布局
当 DOM 深度超过 6 层（比如连续嵌套 <div><div><div><div><div><div>），哪怕只是读取 <code>offsetHeight 或 getBoundingClientRect()，都可能触发 forced synchronous layout，导致滚动或动画卡顿。
最容易被忽略的一点是：BEM 不是命名游戏，它是对组件边界的硬约束。一旦你允许 .card__header__title 这种写法存在，就等于默认接受样式强耦合于 DOM 层级——而那个层级，很可能在下个迭代就被重构掉。
