CSS通配符性能影响及优化技巧

CSS通配符*确实会影响性能，但并非“一用就慢”，其危害程度高度依赖使用场景：当*出现在选择器开头且缺乏父级限定（如*[aria-hidden="true"]或*>.tooltip）时，会强制浏览器遍历整个DOM树，显著拖慢CSSOM构建；而被强上下文约束（如.modal *或svg *）或配合高效定位机制（如* + p）时，现代浏览器优化已能将其影响降至极低。真正关键的不是禁用*，而是构建可预测的匹配路径——优先使用具体标签、添加作用域class、善用:where()降权、为属性选择器加唯一前缀，并意识到DOM频繁变动本身才是样式计算压力的更大源头。

通配符 * 真的会拖慢渲染吗

会，但只在特定场景下显著——不是所有 * 都致命，关键看它出现在选择器的什么位置、匹配范围有多大。浏览器对 * 的处理是“先生成所有元素候选集，再逐个比对后续条件”，如果前面没约束，就真得遍历整个 DOM 树。

比如 *.btn 实际等价于“查所有元素，再筛出 class 含 btn 的”，而 button.btn 或 .container *.btn 就能靠标签名或父级 class 快速缩小候选集。

* 出现在复合选择器开头最危险

这是性能杀手最常见的写法。浏览器无法跳过任何节点，必须从 document 根开始检查每一个元素是否满足后续条件。

• *[aria-hidden="true"]：扫描全部元素找带该属性的，DOM 超过 5000 节点时，CSSOM 构建延迟明显可感
• * > .tooltip：强制对每个父元素检查直接子元素，比 .tooltip 多一次层级遍历
• body *:hover：不仅匹配开销大，还可能触发重排重绘链式反应（尤其配合 transform 或 width 变化时）

哪些地方用 * 影响其实很小

当 * 被强上下文限制，或仅用于极小局部时，现代浏览器优化已足够好。

• .modal *::before：只在 .modal 子树内匹配，DOM 片段通常很轻量
• svg * { pointer-events: none; }：SVG 内元素数量有限，且该规则极少重计算
• * + p：虽然开头是 *，但 CSS 引擎能利用兄弟关系快速定位，实测影响微乎其微

真正要警惕的是没有父级限定、又带属性/伪类/后代组合的全局 *，比如 *[data-track] input:focus。

替代方案比“禁用 *”更重要

不用 * 不等于性能就好，关键是让选择器具备可预测的匹配路径。

• 用具体标签代替：把 *.icon 改成 i.icon, svg.icon, span.icon（更明确，也利于 tree-shaking）
• 加作用域 class：全局重置类写成 .reset-base * { margin: 0; }，而非 * { margin: 0; }
• 用 :where() 包裹降权：:where(*)[data-legacy] { font-size: 12px; } 不影响 specificity，也避免意外覆盖
• 属性选择器尽量带前缀：[data-testid] 比 [id] 更安全，因为 id 在页面中唯一，浏览器有索引优化；而泛用 [class] 会绕过所有索引

最常被忽略的一点：即使改了选择器，如果对应元素仍频繁增删（如虚拟滚动列表里不断 append/remove），样式计算压力依然来自 DOM 变动本身，而非 * —— 这时候该看的是如何减少重排，而不是纠结通配符。

今天关于《CSS通配符性能影响及优化技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！