深层嵌套选择器（>4层）拖慢渲染，因浏览器从右向左匹配，回溯路径长、样式计算开销大，且难以缓存；应控制在3层内，用语义化class替代。
为什么深层嵌套选择器会拖慢渲染
浏览器解析 CSS 选择器是从右往左匹配的，比如 .nav ul li a:hover，它先找所有 a:hover，再向上逐层验证父级是否满足 li、ul、.nav。嵌套越深，回溯路径越长，匹配开销越大；尤其当 DOM 节点多时，这种“先抓再筛”的方式容易触发不必要的样式计算和重排。
- 深层嵌套（>4 层）在移动端或低端设备上可能明显卡顿
- 动态添加/删除 class 时，若依赖深层结构，JS 查询（如
querySelector）也会变慢 - 浏览器无法有效缓存复杂选择器的匹配结果，每次 style recalc 都要重跑
建议把嵌套控制在 3 层以内，优先用语义化 class，例如把 .header .nav .menu .item a 改成 .nav-item-link。
通配符 * 和属性选择器为何要慎用
<em></em> 选择器强制浏览器遍历全部节点，哪怕只写一条 { box-sizing: border-box; }，首次渲染时也要对每个元素做匹配；更危险的是 <em> + </em> 或 *[class^="icon-"] 这类组合——它们无法被索引优化，且在 DOM 变动（如插入新节点）时会重新全量扫描。
-
*在 CSSOM 构建阶段就增加解析耗时，影响首屏时间 - 属性选择器（如
[type="text"]）没有 class 那么快，特别是带正则语义的（[class~="btn"]） - 若必须重置，用更窄的作用域：比如只对
form内部用form * { margin: 0; }，而不是全局
替代方案：用 inherit 或显式重置关键属性，或用 BEM 命名约定避免依赖属性推导。
立即学习“前端免费学习笔记（深入）”；
哪些选择器实际最快？优先级怎么排
浏览器对选择器的匹配效率差异很大，从快到慢大致是：
-
.class（有 class 索引，最快） -
#id（唯一，但现代开发中应少用，不利于复用） -
element（如div，依赖 tag 索引，较快） -
.class1.class2（多个 class 同时存在，仍可索引） -
.class > .child（子选择器，比后代快，但仍有层级开销） -
.class + .sibling（相邻兄弟，性能尚可） -
.class ~ .general-sibling（通用兄弟，需遍历后续同级） -
.class [descendant]（后代选择器，最慢常见类型之一）
注意：:is() 和 :where() 本身不慢，但里面塞进低效选择器（如 :is(.a .b .c, *[data-foo])）依然拉胯。
重绘（repaint）和重排（reflow）真能靠选择器优化？
单纯改选择器写法不能直接减少重绘，但它影响 style 计算阶段的耗时——而 style 计算是重排/重绘链路的第一步。如果样式计算太慢，就会挤压 layout 和 paint 的时间，导致帧率下降，尤其在动画或滚动中。
- 修改
color、background-color触发 repaint，选好选择器能让 repaint 更快完成 - 修改
width、margin、display触发 reflow，此时选择器效率影响更大，因为要重新计算整个布局树 - 使用
will-change: transform或transform: translateZ(0)可以把元素提升为独立图层，绕过部分样式计算，但这只是补救，不是替代选择器优化
真正容易被忽略的是：即使 CSS 规则没生效（比如对应元素不存在），只要它在样式表里，浏览器仍要解析、编译、尝试匹配。所以删掉不用的选择器，比调优还重要。
