深层dom下后代选择器性能急剧恶化，因浏览器从右向左回溯：先找所有.title，再逐个向上验证.parent链，节点超1400后recalculate style时间指数级飙升，5000节点时4层选择器比bem类名慢3.2倍。
深层DOM结构下，后代选择器（如 .page .main .content .title）不是“写得更精确”，而是让浏览器多做大量无效回溯——它直接拖慢样式计算，且问题在节点超1000个后急剧恶化。
后代选择器匹配实际是“从右往左暴力回溯”
浏览器不按你写的顺序从左到右找元素，而是先定位所有 .title 节点，再对每个节点逐层向上检查父级是否依次为 .content → .main → .page。DOM越深、.title越多，这个验证链就越长。
- 2000个
.title节点时，平均每个要向上遍历 3–4 层，总匹配开销非线性增长 - 哪怕其中99%的
.title最终不满足父级条件，浏览器也必须完整走完回溯路径 - 失败匹配的成本，往往比成功匹配还高
DOM节点数破千后，耗时不是翻倍，而是跳变
Lighthouse 将 1400 个节点设为警戒线，是因为实测中 Recalculate Style 时间在此之后不再是线性上升，而是指数级飙升。
- 5000节点页面中，4层后代选择器比等效 BEM 类名（如
.title或.content__title）慢 3.2 倍 - 单次样式重算从 8ms 拉升至 26ms，滚动或 hover 时频繁触发，直接导致掉帧
- 低端 Android 设备上，同场景下可能比平级类名慢 4 倍以上
嵌套越深，JS操作和调试也越不可控
高特异性不是“更稳”，而是把后续所有动态样式更新都绑死在一条脆弱路径上。
-
.a .b .c .d的 specificity 是0,0,4,0，而.d只有0,0,1,0；用el.classList.add('is-hidden')几乎无法覆盖 - DevTools “已计算样式”里真正生效的规则常被压在十几条失效规则之下，人工验证需反复确认父级是否存在、class 是否拼错
-
querySelector('.a .b .c')查询本身也会变慢，尤其在虚拟滚动或动态插入场景中
真正容易被忽略的是：问题不只出在“写了多深”，而在于“每多一层，浏览器都要为每个右端节点重复一次完整祖先链验证”。哪怕 DOM 结构没变，只要节点数涨到临界点，性能就会断崖下跌。这不是渐进式退化，而是匹配机制决定的硬性瓶颈。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
