CSS :has 和 :is() 组合后为什么样式优先级变了

CSS :has() 和 :is() 组合后，样式优先级看起来“突然变高”，通常不是浏览器忽略了书写顺序，而是括号里的选择器也参与了优先级计算。两个伪类本身都不直接增加权重；真正影响结果的是参数列表中优先级最高的选择器。

排查时先把选择器写成 ID-类/属性/伪类-元素三列，再看 :is() 和 :has() 参数中的最高值。若只是想把多个条件合并、又不想抬高权重，把内部的 :is() 换成 :where()，通常比追加 !important 更稳。

先把组合选择器拆成三列

CSS 优先级可以写成 ID-类/属性/伪类-元素/伪元素 三列。比较两个冲突规则时，先比较 ID 列，再比较类列，最后比较元素列；三列完全相同才看同一来源、同一层中的声明顺序。

:is()、:has() 和 :not() 本身不作为普通伪类计入，但它们的参数会计入。参数是一个逗号分隔的选择器列表时，整个列表取其中最高的优先级，而不是根据当前命中的分支临时换算。

.panel:has(:is(.warning, #critical)) {
  /* 外层 .panel 是 0-1-0；:is() 参数取 #critical 的 1-0-0 */
  /* :has() 自身不加分，所以总优先级是 1-1-0 */
  border-color: crimson;
}

.panel:has(:where(.warning, #critical)) {
  /* :where() 及其参数恒为 0-0-0，整体只剩 .panel 的 0-1-0 */
  border-color: darkorange;
}

上面两个选择器的匹配条件可以相近，但覆盖能力完全不同。第一个把参数列表里的 ID 权重带到了外层；第二个仍然可以匹配条件，却把这一段条件的权重压成零。

用具体例子定位为什么后写规则仍然输

假设卡片既要在包含错误提示时标红，也要在被用户选中时显示蓝色边框：

.card.is-selected {
  /* 两个类选择器：0-2-0 */
  border-color: royalblue;
}

.card:has(:is(.error, #urgent)) {
  /* .card 为 0-1-0，参数最高项 #urgent 为 1-0-0 */
  /* 合计 1-1-0，ID 列高于上面的 0-2-0 */
  border-color: crimson;
}

当卡片内命中 .error 时，很多人会直觉地认为只应按 .error 的类权重计算。但在这个组合选择器里，:is(.error, #urgent) 的参数列表包含一个 ID，整体采用最高的 1-0-0。所以即便 .card.is-selected 写在后面，只要另一条规则的 ID 列更高，单靠“把代码移到后面”也不能解决覆盖。

排查时还要把“选择器是否命中”和“命中后谁获胜”分开。元素没有匹配 :has() 的相对选择器时，是匹配问题；两条规则都命中但颜色不对时，才进入优先级、来源、级联层、!important 和顺序的比较。

用 :where() 降低组合条件的隐性权重

如果 :is() 只是为了把多个状态写在一处，而不是有意提高覆盖能力，优先考虑 :where()。它的选择能力和分组方式类似，但自身及参数的优先级固定为 0-0-0。

.card:has(:where(.error, [data-level="urgent"])) {
  /* 只让 .card 提供 0-1-0，内部条件不抢占组件状态规则 */
  border-color: crimson;
}

.card.is-selected {
  /* 0-2-0，因此选中态可以稳定覆盖上面的提示边框 */
  border-color: royalblue;
}

这里的设计意图更清楚：:has() 负责判断卡片内部是否存在某种状态，.card 负责定位组件，.is-selected 负责业务状态。条件越像“实现细节”，越适合放在 :where() 里；条件越像需要强制覆盖的组件状态，才考虑保留明确的类权重。

按维护场景选择拆分、级联层和结构调整

把问题修好不等于把某条规则的权重继续抬高。可以按以下顺序处理：

1. 参数不需要高权重：把 :is() 换成 :where()，让组件状态保持可覆盖。
2. 两个分支确实需要不同优先级：拆成两条规则，分别写清普通状态和高优先级状态，避免一个列表把权重传给所有分支。
3. 来源是第三方样式：优先使用级联层管理来源顺序，再通过低权重的本地规则覆盖，而不是不断增加选择器长度。
4. 选择器已经复杂到难以解释：回到 HTML 的语义类或明确的状态类，减少把 ID、属性和多层关系选择器混在一个条件里。
5. 最后才考虑 !important：如果必须使用，要在代码旁写明它解决的是哪个外部约束，否则后续维护很容易继续叠加更强规则。

例如，组件库可以把内部结构条件保持为零权重，把对外可覆盖的状态交给普通类：

.notice:has(:where(.icon, [data-state="invalid"])) {
  /* 内部结构只负责触发提示，不锁死外部主题的覆盖空间 */
  outline-color: orange;
}

.notice.is-selected {
  /* 对外状态使用稳定、可读的类名 */
  outline-color: royalblue;
}

建立一套快速排查清单

遇到“明明写在后面却不生效”时，可以按下面的顺序缩小范围：

记住一个实用判断：:has() 解决“根据后代或兄弟关系选择外层元素”，:is() 解决“把多个选择分支归并”，它们都不是自动的“加权按钮”。真正让样式变强的，往往是参数列表里无意带入了高权重选择器。

常见延伸问题

:has() 里的多个参数是取命中的那一项吗？

用于优先级计算时，参数列表采用最高优先级项。不要因为当前元素命中的是类选择器，就假定列表中的 ID 不会影响整体。

把 :is() 换成 :where() 会改变匹配范围吗？

在选择器列表和结构相同的情况下，主要变化是优先级，不是把条件从“或”变成“且”。但仍要注意 :where() 的参数语法和嵌套位置。

为什么不直接给覆盖规则加 !important？

!important 会把问题推到更高的级联层级，短期见效但会让后续覆盖更难。先去除参数里的意外高权重，通常能保留更清晰的组件边界。

参考资料：https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:has、https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:is、https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Cascade/Specificity