css选择器性能影响极大，关键选择器决定匹配效率：应避免a:hover、div/p/*及深层嵌套，优先用bem类名如.card__title，属性选择器勿置右侧，需通过performance面板监控recalculate style耗时。
影响非常大，尤其在中大型项目或低端设备上，CSS选择器写法不当会导致 Recalculate Style 耗时飙升数毫秒甚至十几毫秒——这直接拖慢首屏渲染、滚动响应和 hover 动画的帧率。
关键选择器决定匹配起点
浏览器从右往左匹配，最右边那个部分（即“关键选择器”）决定初始筛选范围。它不是语法上的“重点”，而是性能上的“瓶颈锚点”。
-
a:hover是低效的关键选择器：页面有 200 个<a></a>，就得检查 200 次祖先链 -
.nav-link:hover是高效的关键选择器：浏览器靠 class 哈希表直接定位，几乎无额外开销 -
div、p、*这类标签或通配符作关键选择器时，等于告诉浏览器“扫全页所有对应节点”，DOM 超过 1000 个就明显卡顿
深层嵌套比你想象中更伤性能
超过 3 层的后代选择器（如 .card .content .title span）不是“多写几个点”的问题，而是匹配路径爆炸：每个 span 都要向上遍历至少 3 层父级验证，且无法提前终止。
- 子选择器
.card > .content > .title比后代选择器快，因为只查直接父级，路径长度固定 - 真实项目中，
section article div p em这种写法，关键选择器是em，哪怕只有 10 个em，每个都要验证 4 层结构 - DevTools Performance 面板里
Recalculate Style时间突增，90% 情况下就是这类选择器在作祟
属性选择器不是不能用，但位置很关键
[type="text"] 单独用基本不慢，但一旦放在关键位置（最右边），或者和深层嵌套组合，就会触发线性扫描 + 多层回溯的双重开销。
-
.form-input[data-type="email"]安全：关键选择器是.form-input，class 哈希查找 O(1) -
form div * [data-type="email"]危险：关键选择器是[data-type="email"]，需遍历全部节点；再叠加*和form div，实测 layout 耗时可跳到 4.7ms+ -
[class^="icon-"]比.icon-home慢一个数量级：前者无法利用 class 索引，每次都要字符串前缀扫描
BEM 类名不是为了好看，而是为性能让路
像 .card__title 这种单类名，不是命名洁癖，是让每个样式规则都平级、可哈希、易缓存。它规避了结构依赖，也绕开了浏览器匹配时最耗时的“向上回溯”逻辑。
- 替换
.card .title→.card__title：消除后代关系，关键选择器从泛化的.title变成精准的.card__title - 替换
.card [data-role="title"]→.card__title：避免属性扫描 + 多层回溯的双杀组合 - BEM 类名长度略增，但 gzip 后体积几乎无差别；而减少的 style recalc 时间，在首屏和交互中收益显著
真正容易被忽略的点是：性能问题往往在 DevTools 里不报错、不警告，只表现为滚动掉帧、hover 延迟、Lighthouse 的 “Avoid complex selectors” 提示一闪而过——得主动打开 Performance 面板，盯着 Recalculate Style 时间看，才能揪出那些“看起来没问题”的选择器。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
