是，但仅在特定场景下显著；*出现在选择器开头最危险，如*[aria-hidden="true"]或*>.tooltip会强制遍历整个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 变动本身，而非 * —— 这时候该看的是如何减少重排，而不是纠结通配符。
