超大型DOM下选择器匹配开销呈非线性增长，根源在于CSS从右向左匹配机制：每多一层空格分隔选择器（如.list .item .title），浏览器需对每个目标元素向上遍历验证父级，DOM越深、节点越多，回溯路径越长、耗时越呈指数级上升；实测5000节点页面中4层后代选择器比BEM单类名慢3.2倍，Recalculate Style时间从8ms升至26ms。
超大型DOM下，选择器匹配开销呈非线性增长
当 DOM 节点超过 1400 个（Lighthouse 警戒线），浏览器样式计算阶段的耗时不再线性上升，而是指数级跳变。根源在于 CSS 选择器从右向左匹配——每多一层空格分隔（如 .list .item .title），浏览器就要对每个 .title 向上遍历父级验证，而 DOM 越深、分支越多，回溯路径越长。实测显示：在含 5000 个节点的列表页中，一个 4 层后代选择器比等效 BEM 类名（如 .item__title）慢 3.2 倍，Recalculate Style 时间从 8ms 拉升至 26ms。
标签选择器和通配符在大DOM里会触发全量扫描
* 和 div 这类选择器没有索引能力，浏览器必须逐个检查所有节点是否匹配。哪怕只写一条 * { box-sizing: border-box; }，在 10k 节点页面中也会额外增加 15–22ms 首次样式计算时间；而 div 在滚动列表中被高频重绘时，每次 layout 触发都要重新扫描全部 div 元素，CPU 占用直接飙升。更隐蔽的是 [data-id] .item 这类“看似局部”的规则——只要它命中动态插入的子项，就会拖慢整个虚拟滚动链路。
高特异性选择器让动态样式更新成本翻倍
深层嵌套（如 .page .main .section .card .header）生成的 specificity 是 0,0,4,0，后续 JS 用 el.classList.add('is-hidden') 几乎无法覆盖，只能靠 !important 或更重的选择器补救，形成恶性循环。DevTools 里“已计算样式”面板中，真正生效的规则常被压在十几层被覆盖的旧规则之下，人工定位需反复验证父级路径是否成立；VS Code 的 CSS Peek 功能也常跳转错误层级。这不是调试体验问题，而是每次 class 切换都强制浏览器重跑整条匹配链。
CSS 变量 + 深层选择器 = 样式匹配雪崩
单独用 var(--color) 不卡，但和深层选择器叠加就危险：.modal .content .text { color: var(--text-color); } 会让浏览器对每个匹配到的 .text 同时做两件事：向上查找最近定义 --text-color 的祖先、再走一遍继承与计算逻辑。500 个 .text 平均查 3–4 层，Chrome Performance 面板里「Recalculate Style」可能占主线程 CPU 40% 以上。更致命的是，哪怕只改一次 :root 上的变量值，所有含该 var() 的规则都会被标记为“需重算”，触发全量样式更新而非局部。
立即学习“前端免费学习笔记（深入）”；
真正卡住你的，往往不是某条规则写得多差，而是它被多少节点命中、在什么时机被触发、以及是否和其他机制（如 JS 动态 class、CSS 变量、滚动重绘）耦合在一起——这些细节在小页面里毫无感知，一到超大型 DOM 就立刻暴露。
