一个需要父选择器的场景
表单校验是前端最常见的交互之一。用户输入邮箱后，如果格式错误，页面需要在输入框下方显示提示文字，并让输入框本身变红。传统做法是监听 input 事件，用 JavaScript 判断校验结果，然后给输入框的父容器添加或移除一个 has-error 类，CSS 再根据这个类来改变样式。
这种做法可行，但存在两个问题。第一，校验逻辑和样式状态耦合在 JavaScript 里，每次校验都要手动操作 DOM 类名，代码分散且容易遗漏。第二，类名切换会触发样式重算，如果页面上有大量表单字段，频繁的类名变更可能造成可感知的卡顿。
:has() 选择器提供了一种纯 CSS 的替代方案：让父元素的样式直接依赖子元素的状态。例如，当输入框处于 :invalid 状态时，父容器可以自动显示错误提示并改变边框颜色，完全不需要 JavaScript 参与。这听起来很理想，但它如何工作？浏览器如何知道父元素需要更新样式？性能代价又是什么？
:has() 是什么：关系型选择器的核心机制
:has() 是 CSS Selectors Level 4 定义的关系型伪类。它接受一个相对选择器列表作为参数，当参数中的任意一个选择器能匹配到当前元素的某个后代、兄弟或后续兄弟时，当前元素就被选中。用正则表达式类比，:has() 相当于前瞻断言：它向后查看元素之后的内容，但匹配的是当前元素本身。
最简单的用法是选择包含特定子元素的父元素。例如 section:has(.featured) 会选中所有包含 class 为 featured 的后代的 section 元素。:has() 也可以配合子组合器 > 只检查直接子元素，如 parent:has(> child)。
:has() 不仅能向上选择父元素，还能选择前一个兄弟元素。例如 h1:has(+ h2) 会选中后面紧跟着 h2 的 h1，从而调整标题间距。这种能力在以前只能通过 JavaScript 或给 HTML 加额外类来实现。
关键限制：:has() 不能嵌套在另一个 :has() 内部，也不能包含伪元素，因为伪元素的存在依赖于祖先的样式，这会造成循环查询。这些限制保证了选择器的可计算性。
样式失效：浏览器如何知道父元素需要更新
当 DOM 发生变化时，浏览器需要找出哪些元素的样式可能受影响，并标记它们进行重算。这个过程称为样式失效（style invalidation）。传统选择器如 .a .b 的失效范围很明确：当某个元素的 class 变为 a 时，只需要检查它的后代中是否有 class 为 b 的元素。
:has() 打破了这种单向关系。对于规则 .a:has(.b)，当子元素 .b 的 class 发生变化时，父元素 .a 的样式可能也需要更新。这意味着失效方向是反向的：从子元素向上传播到祖先。
Blink 引擎（Chrome 的渲染引擎）使用“失效集合”（Invalidation Sets）来管理这一过程。每个选择器都会被分解为多个失效集合，每个集合对应一种 DOM 变化（如 class 变化、属性变化、子元素插入等）。当某个元素发生变化时，引擎会查询与该变化相关的失效集合，找到可能受影响的元素并标记它们。
对于 :has()，Blink 需要额外处理“反向”关系。当子元素 .b 变化时，引擎必须向上遍历 DOM 树，检查每个祖先元素是否匹配 .a:has(.b)。为了避免遍历整棵树，Blink 引入了“反向失效集合”（inverted invalidation sets），它记录了哪些选择器可能受某个 class 或属性变化的影响，从而缩小检查范围。
WebKit 也实现了类似机制，并加入了缓存和过滤优化。这些优化使得 :has() 在实际页面中不会造成明显的性能退化，但代价是实现的复杂性显著增加。
贯穿场景：邮箱输入框的校验提示
我们用一个具体的表单场景贯穿全文。假设有一个注册表单，包含一个邮箱输入框和一个提示信息。HTML 结构如下：
<div class="form-field">
<input type="email" required>
<p class="error-message">请输入有效的邮箱地址</p>
</div>我们希望当输入框内容无效时，.form-field 显示红色边框，.error-message 变为可见。使用 :has() 可以这样写：
.form-field:has(input:invalid) {
border-color: red;
}
.form-field:has(input:invalid) .error-message {
display: block;
}当用户输入非法邮箱时，:invalid 状态自动生效，父容器的样式随之改变。整个过程不需要 JavaScript 监听事件或切换类名。
这个场景贯穿后续的性能分析：当输入框的校验状态变化时，浏览器需要更新哪些元素的样式？代价有多大？
样式计算与重算流程
当输入框的值变化导致 :invalid 状态改变时，浏览器需要重新计算样式。完整的流程如下：
- DOM 变更：用户输入触发输入框的 value 变化，浏览器更新 DOM 属性。
- 样式失效：浏览器检测到输入框的伪类状态（
:invalid）可能变化，根据失效集合找到需要重算的元素。对于:has()规则，需要向上检查祖先元素。 - 样式重算：对标记的元素重新匹配所有选择器，计算最终样式。
- 布局重算：如果样式变化影响几何属性（如边框宽度、尺寸），则触发布局（layout）计算。
- 绘制与合成：更新后的样式被绘制到屏幕上。
display: block 和 border-color 的变化都会影响布局。border-color 本身不改变盒模型，但 display 从 none 变为 block 会改变布局。因此，当错误提示从隐藏变为显示时，必然触发布局重算。
相比之下，如果只改变 color 或 background-color，可能只触发绘制而不触发布局。但 :has() 本身并不决定是否触发布局，它只影响选择器匹配，最终是否重算布局取决于样式属性。
性能开销：对整棵子树的影响
:has() 的主要性能风险在于，当子元素状态变化时，可能需要检查多个祖先元素，甚至整个子树。例如，如果规则是 body:has(.error)，那么任何 .error 元素的出现或消失都会导致 body 的样式重算，进而可能影响整个页面。
Blink 和 WebKit 都采取了优化措施来减少不必要的检查。Blink 使用反向失效集合，只检查可能匹配的祖先。WebKit 则实现了缓存，记录元素与 :has() 选择器的匹配结果，避免重复计算。
然而，这些优化并不能完全消除性能开销。当 :has() 的参数非常复杂（如包含多个组合器或逻辑组合）时，匹配成本会上升。此外，如果 :has() 作用于一个元素，而该元素的子元素频繁变化（如动画或实时输入），则每次变化都可能触发祖先的样式重算。
在表单校验场景中，输入框的 :invalid 状态变化频率较低（用户停止输入后才会校验），因此性能影响可以忽略。但如果将 :has() 用于高频变化的场景，如拖拽或动画，就需要谨慎评估。
对比传统 JS 类名切换方案
传统方案中，JavaScript 监听输入事件，校验后切换父容器的 has-error 类。CSS 规则为 .form-field.has-error { ... }。
两种方案的性能差异主要体现在样式失效的粒度上。
| 对比维度 | :has() 方案 | JS 类名切换方案 |
|---|---|---|
| 样式失效方向 | 子元素变化向上传播，可能检查多个祖先 | 类名变化直接作用于目标元素，失效范围明确 |
| 匹配成本 | 每次状态变化需重新匹配 :has() 参数 | 类名选择器匹配简单，成本低 |
| 实现复杂度 | 纯 CSS，无需 JavaScript | 需要编写事件监听和类名操作逻辑 |
| 可维护性 | 样式逻辑集中在 CSS，易于维护 | 校验逻辑与样式状态耦合在 JS 中 |
| 适用场景 | 状态变化频率低、DOM 结构简单的场景 | 兼容性要求高或需要复杂逻辑的场景 |
需要说明的是，JS 类名切换的失效范围虽然更小，但 JavaScript 本身的执行也有开销。如果校验逻辑复杂，JS 方案的总成本可能更高。而 :has() 将匹配工作交给浏览器，减少了 JavaScript 运行时间，但增加了样式重算的复杂度。
失败模式与适用边界
:has() 并非万能。以下情况需要特别注意：
- 浏览器兼容性：
:has()自 2023 年 12 月起在主流浏览器中广泛可用，但旧浏览器不支持。在不支持的浏览器中，整个选择器块会失效，除非使用:is()或:where()包裹。可以使用@supports selector(:has(...))进行特性检测。 - 循环依赖：
:has()不能嵌套，也不能查询伪元素，否则可能导致循环计算。 - 性能陷阱：避免在大型文档中使用过于宽泛的
:has()选择器，如body:has(div)，这会导致每次子元素变化都检查整个文档。 - 可访问性：
:has()本身不影响可访问性，但依赖视觉状态的样式（如错误提示）应配合 ARIA 属性，确保屏幕阅读器能感知。
在表单校验场景中，:has() 适合校验逻辑简单、状态变化不频繁的情况。如果校验规则复杂（如异步验证、多字段联动），仍需要 JavaScript 处理，此时 :has() 只能作为增强手段。
诊断与优化建议
要评估 :has() 的性能影响，可以使用 Chrome DevTools 的 Performance 面板，观察样式重算（Recalculate Style）的时间。如果发现重算时间过长，可以检查是否由 :has() 引起。
优化建议：
- 保持
:has()参数简单，避免使用长后代选择器。 - 将
:has()应用于局部容器，而不是全局元素。 - 结合
:where()降低特异性，避免影响其他规则。 - 对于高频变化，考虑使用类名切换或 CSS 自定义属性。
结论
:has() 提供了一种优雅的纯 CSS 方式来表达父元素对子元素的依赖，减少了 JavaScript 的参与。它的性能关键在于浏览器引擎的失效优化，但开发者仍需注意选择器的复杂度和作用范围。在表单校验这类低频变化场景中，:has() 是一个可靠的选择；在高频变化或复杂逻辑场景中，传统 JS 方案可能更可控。
理解 :has() 的失效机制，有助于在合适的场景中发挥它的优势，避免性能陷阱。
附：样式失效流程示意
以下流程图展示了输入框状态变化时，:has() 规则如何触发样式重算：
flowchart TD
A[用户输入] --> B[输入框 value 变化]
B --> C{浏览器检测 :invalid 状态变化}
C -->|变化| D[触发样式失效]
D --> E[检查祖先元素是否匹配 :has()]
E --> F[标记 .form-field 需要重算]
F --> G[样式重算]
G --> H[布局重算]
H --> I[绘制与合成]
C -->|无变化| J[不触发失效]
在这个流程中，关键转折点是“检查祖先元素”。如果没有 :has()，浏览器只需关注输入框本身；有了 :has()，它必须向上遍历，这增加了检查成本，但通过失效集合的优化，实际影响被控制在可接受范围内。