CSS选择器优先级是由specificity权重系统决定的，而非声明顺序；其计分规则为ID（100）、类/属性/伪类（10）、标签/伪元素（1）三部分构成，!important不参与计算但会强制覆盖。
什么是 CSS 选择器优先级？它不是“谁写在后面就赢了”
CSS 优先级决定当多个规则作用于同一个元素时，哪条声明最终生效。它不是靠顺序或“后声明覆盖前声明”这种简单逻辑，而是由一套可计算的权重系统决定。这个权重叫 specificity，浏览器用它算出每个选择器的得分，得分高者胜出。
常见误解是“ID 选择器一定比类高”，但其实 #header .nav li a（1 个 ID + 2 个类 + 2 个标签）的 specificity 是 1-2-2，而 .menu-item.active:hover（3 个类 + 1 个伪类）是 0-3-1，前者仍更高。关键在于拆解结构，而不是数“有几个类”。
具体计分规则（从左到右三位数）：
-
100：每个 ID 选择器（如#app） -
10：每个类、属性、伪类（如.btn、[type="submit"]、:hover） -
1：每个标签名、伪元素（如div、::before）
注意：!important 不属于 specificity 计算，它是强制覆盖机制，会破坏可维护性，应避免在业务样式中使用。
立即学习“前端免费学习笔记（深入）”；
如何快速估算两个选择器谁更“重”？用 Chrome DevTools 看真实值
手动算三位数容易出错，尤其嵌套深、带内联或动态类时。最可靠的方式是打开 Chrome DevTools → 选中元素 → 在 Styles 面板里找对应规则，鼠标悬停在选择器上，会显示类似 0,1,0,1 的 specificity 值（格式为 inline-ID-class-tag）。
实操建议：
- 遇到样式没生效，先点开该元素，确认目标规则是否被划掉（strikethrough），再看旁边有没有更高 specificity 的规则在生效
- 如果看到某条规则写了
!important，别急着加自己的!important，先查清为什么它的 specificity 不够 - 对动态添加的类（如 React 的
className={clsx('btn', isActive && 'btn--active')}），要意识到它生成的选择器和静态写死的可能不在同一量级
为什么用 [data-testid] 写样式会导致优先级失控？
很多团队用 [data-testid="submit-btn"] 这类属性选择器做测试定位，但若顺便拿它写样式，就会引入一个 10 分的权重——而且它和业务类名（如 .btn-primary）同级，极易引发冲突。更糟的是，这类属性通常由自动化脚本注入，无法像类名那样统一管控语义和复用。
正确做法：
- 测试属性只用于
querySelector或 Testing Library 查询，绝不参与样式定义 - 所有样式必须通过语义化类名（如
.form-submit）或 BEM 命名（如.button--primary）控制 - 如果必须用属性选择器（比如针对特定环境的样式），确保它出现在独立的、低优先级的 CSS 文件中，并用注释说明用途
.button {
padding: 8px 16px;
}
.button--primary {
background-color: #007bff;
}
/* ✅ 正确：用类控制样式 */
[data-testid="submit-btn"] {
/* ❌ 错误：混用测试属性写样式，且无上下文约束 */
}组件化开发中，scoped CSS 或 CSS Modules 怎么影响优先级？
Vue 的 和 CSS Modules 本质是通过自动添加唯一属性（如 data-v-f3f4f5）来实现样式隔离，这相当于给每个选择器末尾加了一个属性选择器——也就是额外 +10 分。这意味着即使你写 .card { color: red; }，实际编译后可能是 .card[data-v-f3f4f5] { color: red; }，它的 specificity 变成 0-1-1，比全局的 .card（0-1-0）更高。
隐患就在这里：当你在父组件里试图用更“通用”的规则覆盖子组件样式时（比如想统一改所有卡片标题颜色），很可能因为子组件样式自带 data-xxx 而失败。
应对方式：
- 避免跨组件强覆盖；优先用 props 控制子组件内部样式变体（如
- 真需覆盖时，用同样带 scope 属性的选择器，例如
.card[data-v-f3f4f5] .title，或利用:deep()（Vue）/:global()（CSS Modules）明确穿透层级 - 警惕 Webpack 的
css-loader默认开启modules.auto，可能让普通.css文件也被意外模块化
真正难处理的不是算分本身，而是团队协作中没人主动检查 specificity 变化——尤其当样式从全局迁移到 scoped、或多人共用同一份 UI 库时，细微的权重偏移会让视觉回归测试都难以发现。
