通配选择器 * 会让 CSS 变慢，因为它强制浏览器检查 DOM 中每个节点，无法剪枝，尤其在深层嵌套页面中显著拖慢样式计算；应避免全局重置，改用语义类名或原子化方案。
通配选择器 * 为什么会让 CSS 变慢
浏览器匹配 CSS 选择器是从右往左进行的，* 作为最宽泛的右端匹配项，会强制引擎检查 DOM 中每一个节点——哪怕你只打算给某个特定容器下的元素加样式。* 自身不带任何约束，无法被浏览器快速剪枝，尤其在深层嵌套或大型页面中，它会显著拖慢样式计算和重排。
- 避免写成
* { margin: 0; }这类全局重置，改用更具体的重置策略（如body, h1, p, ul, li { margin: 0; }） -
*在伪类或属性选择器右侧时危害更大，例如div *:hover，会先找所有子元素再过滤 hover 状态 - 现代 CSS 重置库（如 modern-normalize）已完全弃用
*，转而逐标签精细控制
标签组合选择器（如 ul li a）的实际性能开销
看似“具体”的后代组合，如果层级过深或起点太宽，效率反而不如更短、更靠右的选择器。比如 body div ul li a，浏览器要从 body 开始逐层向下找，中间任意一层匹配失败都得回溯；而 .nav-link 这种类名选择器可直接通过哈希表定位。
- 超过 3 层的后代选择器（如
section article footer p em）应警惕：DOM 变动时重计算成本高 - 用子选择器
>替代空格能明确限制层级，例如ul > li > a比ul li a更易优化，但依然不如.menu-item a - 当必须用标签组合时，把最特异的标签放在最右边（如
header nav a比a nav header合理，后者语法错误）
如何用开发者工具验证选择器效率
Chrome DevTools 的 **Rendering > Paint flashing** 和 **Layers** 面板只能看绘制表现，真正查选择器匹配耗时得靠 **Coverage** 面板 + 手动禁用规则，或使用 Performance 面板录制样式计算阶段（Layout / Recalculate Style）。
- 打开 DevTools → ⚙️ Settings → Preferences → Elements → 勾选 “Show user agent shadow DOM” 有助于看清内置样式是否被低效选择器干扰
- 在 Styles 面板中，被灰色划掉的声明不一定是无效，可能是该选择器因匹配失败未应用——注意观察右侧“Computed”里实际生效的来源
- 用
document.querySelector()测试真实匹配速度：console.time('test'); document.querySelectorAll('div * span'); console.timeEnd('test');，对比'.content span'
真正高效的替代写法：语义类名 + BEM 或原子化
放弃“用标签猜结构”的思路，直接为意图命名。比如不再写 article h2，而是用 .article-title；不再依赖 table tr td，而是用 .table-cell。这样既提升可维护性，也彻底规避选择器深度陷阱。
立即学习“前端免费学习笔记（深入）”；
- BEM 中
.card__title--large这类命名让选择器永远是单类名，浏览器一次哈希查找即可 - 原子化方案（如 Tailwind）本质是把样式逻辑移出 CSS 选择器，全部变成内联 class 组合，
class="text-lg font-bold p-4"不含任何层级关系 - 若必须保留部分语义标签结构（如表单），可用
:where()降低权重同时保持可读：:where(fieldset) legend不影响 specificity，便于覆盖
CSS 选择器的“看起来具体”不等于“执行高效”，真正影响性能的是匹配路径长度、候选节点数量和浏览器能否跳过无关分支——这些细节在小项目里不明显，但在组件复用率高、DOM 节点多的 SPA 里，一个 * 或三层后代选择器可能就是首屏卡顿的隐性原因。
