关键选择器太泛会导致全量扫描，浏览器css匹配从右往左，关键选择器决定初始筛选范围，如a:hover、span等需遍历全页节点回溯，而精准类名如.nav-link:hover可哈希定位；深层嵌套、通配符、:not()/:has()组合及伪类验证均显著拖慢样式重计算。
关键选择器太泛会导致全量扫描
浏览器匹配 CSS 是从右往左的，最右边那个选择器就是“关键选择器”。它决定初始筛选范围——a:hover、span、div 这类标签或伪类，会拉取全页对应节点再往上回溯，DOM 越多越慢。
-
a:hover在含 200 个链接的页面里，就得检查 200 次祖先链；换成.nav-link:hover，浏览器直接哈希定位，几乎无额外开销 -
section article div p em的关键选择器是em，哪怕页面只有 10 个em，每个都要验证 4 层父级结构 - ID 选择器
#header理论最快，但现代项目中复用性差，不建议为按钮、列表项等高频元素加 ID
深层嵌套（>3 层）显著拖慢 style recalc
超过 3 层的后代选择器不是语法错误，而是匹配路径爆炸。浏览器每做一次样式重计算（比如滚动、hover、JS 动态改 class），都要重新跑一遍从右到左的回溯逻辑。
-
.card .content .title span：先找所有span，再逐层验父级 → 至少 4 次 DOM 树向上遍历 -
.card__title：单类名，哈希查找，O(1) 时间复杂度 - DevTools Performance 面板中 “Recalculate Style” 耗时突增，90% 情况下就是这类选择器在作祟
- BEM 命名（如
.card__header、.card--expanded）不是为了好看，是为了让每个样式规则都平级、可预测、易缓存
通配符和属性选择器触发强制全量遍历
* 和 [type="text"] 这类选择器没有索引优化路径，每次匹配都得扫完整个 DOM 树，尤其在首屏渲染或动态插入节点时影响明显。
-
* { box-sizing: border-box; }看似省事，实际会让浏览器对每个新创建的节点都执行一次匹配 -
[class^="icon-"]无法利用哈希表，每次都要字符串前缀比对，比.icon-menu慢一个数量级 -
form :invalid不是选中无效元素那么简单——浏览器得对 form 内所有可验证控件调用checkValidity()，大表单下卡顿肉眼可见 - 真要全局重置，用更窄作用域：
form * { margin: 0; }或显式写input, button, select { margin: 0; }
:not() 和 :has() 组合容易踩兼容与性能双坑
否定伪类和容器查询本身有用，但放在关键位置或嵌套使用时，会关闭浏览器的快速匹配路径，且旧版 Safari 支持不一。
-
:not(.valid) input[type="text"]：浏览器放弃哈希查.valid，改为逐个检查每个input是否满足条件 -
section:not([hidden]) [role="button"]：属性 + 否定 + 后代，三重开销叠加 -
:has()在 Safari 15.6 及更早版本完全不支持，Chrome 105+ 才稳定；Lighthouse 审计会报 “Avoid complex selectors using :has()” - 替代方案：
.section--visible .btn（用 JS 控制状态类）比依赖:has(.btn)更可控、更快、更兼容
真正卡住页面的往往不是某条规则写得“不够酷”，而是它悄悄放大了 style recalc 的频次和深度——尤其当它被用于动画、滚动监听或高频交互区域时。类名命名是否语义化、是否可预测、是否隔离作用域，比“用了几个 > 符号”更能决定最终性能。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
