我对 CSS 通用选择器的误解

id > *。这里有个拼写错误。而且我认为这是多余的。你只需要 #id *，级联操作就能完成。最后，* > #id 也是一样的，你只需要 #。

在CSS中，星号*被称为通用选择器。它可以匹配任何类型的所有元素。

* {
    color: red;
}

这个例子会将页面上所有文本的颜色更改为红色（只要没有对元素应用更具体的规则）。

我以前不常用通用选择器，因为我以为选中所有元素会影响页面性能，而且很难修改。但经过一番研究后，我发现之前对通用选择器和 CSS 的一些理解都是错误的。

*特异性为 0

误区一：通用选择器的特异性很高。❌错误！通用选择器的特异性*为零。事实上，引用MDN 关于特异性的文章：

通用选择器 (*)、组合器 (+, >, ~, ' ', ||) 和否定伪类 (:not()) 对特异性没有影响。

因此，仅使用通用选择器（例如）的规则* { color: red }可以被单个元素、类或 ID 选择器覆盖。

Estelle Weyl 的 specifishity 页面是一个极好的可视化指南，可以帮助理解 CSS 特异性。

*就性能而言效率低下

误解二：通用选择器与其他选择器相比性能很差。✅我的说法是对的。

谈到 CSS 选择器的性能，Steve Souder 的研究成果经常被引用，尤其是他2009 年出版的《更快的网站》（Even Faster Websites）一书以及一篇关于 CSS 选择器性能的热门博文。他的网站上有一个方便的CSS 测试工具，可以用来测量 CSS 选择器的性能。通用选择器是性能最差的选择器之一，其他性能较差的选择器还包括属性选择器（例如 `<div> [href="#"]`）、伪类和伪元素（例如:hover`<div>`）。ID 和类是性能最佳的选择器。（Harry Roberts 在 2011 年发表的一篇关于高效 CSS 选择器的文章中总结了这些结果。）

然而，这些结果仅适用于单独使用单个选择器的情况，而不适用于与其他选择器组合的情况。即使不使用单个选择器，您仍然可以编写低效的 CSS 选择器*。使用大量的子选择器或后代选择器是实现这一点的一种方法，例如：div > ul li > a { color: red; }


浏览器从右到左读取 CSS 选择器 ⬅

误区三：浏览器处理 CSS 选择器的顺序是从左到右，和我阅读的顺序一样。❌我之前的想法错了，这让我很惊讶！

其中一条规则运行速度比另一条快：

/* A */
#id > *.

/* B */
* > #id {
    color: red;
}

浏览器会先检查最右边的选择器，然后再向左移动。因此，选择器 B 速度更快，因为它只匹配 ID 相同的元素，而不是像选择器 A 那样匹配文档中的所有元素。

因此，在编写选择器时，最好将类或 ID 等性能较高的内容放在最后。

CSS 选择器性能至关重要

误区四：关注 CSS 选择器效率对页面性能至关重要。❌随着我对这个主题了解的 深入，我发现主流观点是选择器性能无需过分关注。Steve Souder 甚至在前面提到的那篇关于 CSS 选择器性能的博客文章的第一段中也表达了类似的观点。这篇文章写于十年前，而自那时以来，我们的浏览器已经变得强大得多。

但是，我仍然不建议编写过于复杂的筛选器，例如

div a [type="text"] .foo #bar {
    color: red;
}

并非出于性能考虑（尽管这样做效率会很低），而是因为这表明你的 DOM 结构很糟糕，这样编写的 CSS 代码难以维护和覆盖。相反，你应该编写只匹配一个类的选择器。

我会用吗*？

通用选择器我并不常用，但它有时也很有用。常见的浏览器重置类型选择器包括：

* , *:before, *:after {
    box-sizing: border-box;
}

通用选择器也可用于选择元素的所有子元素，或者在您无法直接控制页面结构的情况下使用，例如：

.class > * {
    color: red
}

现在我对它的工作原理有了更深的理解，我会更愿意使用它*，尤其是在考虑页面性能问题时。在这个充斥着体积庞大的首页图片 PNG、臃肿的 JavaScript 包和缓慢的 API 调用的世界里，网站中还有更多值得优化的战略性部分，可以带来更大的性能提升。

相反，如果我确实需要使用通用选择器，我会评估原因：这段 CSS 能否以更清晰、更易于维护的方式编写？或者能否重构页面结构，以便更容易地定位到所需的元素？

你经常使用通用选择器吗？还是尽量避免使用？

题图由 Jeremy Thomas 拍摄，来自 Unsplash。