.nav ul li a 比 .nav-link 慢，因前者需从所有 a 元素右向左逐级回溯父级匹配，dom 节点多时开销剧增；后者为单类名，哈希查找近乎零成本。
为什么 .nav ul li a 比 .nav-link 慢？
CSS 选择器是从右向左匹配的，浏览器先找所有 a 元素，再逐个向上检查是否在 li 内、是否在 ul 内、父级是否有 .nav。层级越深，回溯越多，尤其在 DOM 节点数过万时，性能差距明显。
而 .nav-link 是单类名，浏览器直接哈希查找，几乎无额外开销。
- 避免用后代选择器（空格）代替必要类名，尤其是用于高频更新或动画的元素
- 层级超过 3 级（如
.header .main-nav .dropdown li a）就该考虑重构 - 伪类如
:hover、:focus-within不影响匹配性能，但触发重排/重绘时才真正拖慢页面
:not() 嵌套和复杂参数会显著拖慢解析
:not() 的参数本身也按右向左规则执行。写成 div:not(.foo .bar) 会让浏览器对每个 div 都去检查其内部是否存在 .foo .bar 结构，实际等价于“查所有 div → 查每个 div 下所有 .foo → 查每个 .foo 下所有 .bar”，开销爆炸。
更糟的是 :not(:not(:not(...))) 这类嵌套，现代浏览器虽有优化，但仍可能触发降级路径。
立即学习“前端免费学习笔记（深入）”；
- 优先用正向类名替代否定逻辑，比如用
.is-active而非:not(.is-inactive) -
:not()参数只用单类名或属性选择器，例如input:not([type="hidden"])是安全的 - 避免
:not()内使用伪类（如:not(:hover)），部分旧版 Safari 会直接忽略
属性选择器和通配符选择器是隐性性能杀手
[class*="btn"]、[href^="/api"] 这类属性选择器无法被 CSS 引擎索引，每次样式计算都要遍历对应标签的所有实例并做字符串匹配。比 .btn-primary 慢一个数量级。
更危险的是 *[role="button"] 或 div[class] —— 它们强制浏览器扫描整个子树中所有元素，且无法被缓存复用。
- 能用类名就不用属性选择器，哪怕多加一个 class（如
class="btn btn--primary js-trigger"） - 避免在关键渲染路径上使用
*或[attr]（不带值的属性存在检查） - 如果必须用属性选择器，确保它绑定在明确标签上，例如
button[data-action]比[data-action]快得多
如何验证选择器真实开销？
Chrome DevTools 的 **Rendering > Paint Flashing** 和 **Layers** 面板只能看绘制，不反映选择器匹配耗时。真正有效的是 Performance 面板录制后展开 Layout 或 Recalculate Style 事件，看其中 Style recalculation 的子项耗时 —— 高亮出的长条往往就来自低效选择器。
另一个轻量方法：临时把可疑 CSS 规则注释掉，用 document.querySelectorAll("your-selector") 在控制台跑一遍，对比不同选择器的执行时间（注意避开首次解析缓存）。
- 不要依赖 “CSS 选择器性能表” 类的过时资料，Chrome 90+ 和 Firefox 100+ 对
.a.b.c多类组合已有较好优化 - 真正拖慢首屏的，往往是那些看似简单却高频触发的规则，比如
body *:not(.skip) { ... } - 最易被忽略的是：CSS-in-JS 库（如 styled-components）生成的动态类名，若未启用 babel 插件提取静态样式，会导致大量内联 style 标签 + 重复选择器解析
