CSS `:has()` 伪类：十年最大变革还是过度承诺？

CSS 终于能"向上选择"了——这个被开发者喊了十年的功能，2022年才正式落地。有人欢呼这是样式表的逻辑革命，也有人质疑：浏览器兼容性还没跟上，急着用是不是给自己挖坑？

这篇我们来拆解 `:has()` 的真实能力边界，看看它到底能替代多少 JavaScript，又在哪些场景下会翻车。

反常识起点：父选择器迟到了十年

CSS 选择器的设计哲学一直是"向下选"——从父元素指向子元素。想要反向操作？过去只能用 JavaScript 监听 DOM 变化，动态加减 class。

`:has()` 打破了这条铁律。语法很简单：`article:has(img)` 选中所有包含图片的 article 元素。但实现难度极高——浏览器需要在匹配父元素前，先遍历检查所有子元素，性能开销呈指数级增长。

这也是为什么 Firefox 直到 2023 年底才完整支持，而 Safari 和 Chrome 虽然早已实现，某些复杂组合仍可能触发重绘性能问题。

所以核心矛盾在于：功能本身强大，但工程化落地需要权衡。

正方：这三类场景确实能省掉 JS

支持方的主要论据集中在减少代码复杂度和提升可维护性。原文列举的实战场景值得逐个验证。

场景一：表单验证的纯 CSS 方案

传统做法需要监听 input 的 invalid 事件，然后给父容器加 error 类。`:has()` 允许这样写：

```css fieldset:has(input:invalid:not(:focus)) { border-color: red; animation: shake 0.3s; } ```

关键点在于`:invalid`和`:not(:focus)`的组合——只在输入无效且未聚焦时触发，避免用户打字时的干扰。这个逻辑以前必须写事件处理器，现在声明式完成。

但限制也很明显：无法获取验证的具体错误信息（如"密码太短"），复杂的跨字段校验（如确认密码匹配）仍然需要脚本。

场景二：组件的自适应布局

卡片组件是典型案例。过去需要后端或 CMS 在渲染时判断"是否有图"，输出`card--with-image`修饰类。`:has()` 让 CSS 自己检测：

```css .card:has(img) { grid-template-areas: "image header" "image content"; } ```

这确实减少了模板层的条件判断，尤其对 headless CMS 或静态站点生成器很友好。但性能代价是：每次 DOM 变化，浏览器都要重新评估`:has()`选择器，图片懒加载时可能出现布局抖动。

场景三：导航的状态联动

原文提到的"mega menu"场景是`:has()`的高光时刻。`nav:has(.submenu:hover)` 让父级导航感知子菜单的悬停状态，自动调整背景或触发页面遮罩。

这替代了过去常见的方案：给 nav 加`is-active`类，或用 JavaScript 计算子菜单位置。DOM 结构更干净，CSS 职责更清晰。

但这里有个隐藏陷阱：`:hover`在触控设备上行为不一致，移动端可能需要额外的`@media (hover: hover)`查询做降级处理。

反方：三个被低估的工程风险

质疑方的声音在中文技术社区较少被系统讨论，但原文的某些表述其实已经暗示了问题。

风险一：性能黑箱

CSS 工作组在规范中明确警告：`:has()`的参数选择器越复杂，计算成本越高。`article:has(.a .b .c)` 这类深层嵌套可能触发"样式计算"性能瓶颈，在低端设备或大型文档中尤为明显。

Chrome DevTools 的 Performance 面板可以监控，但大多数开发者不会主动检测。更麻烦的是，`:has()`的性能特征因浏览器而异——Safari 的优化策略和 Chrome 不同，跨浏览器一致性测试成本上升。

风险二：样式查询的依赖陷阱

原文提到`:has()`"与样式查询（Style Queries）配合极佳"，但这恰恰是个隐患。样式查询允许基于父元素的计算值来设置子元素样式，比如：

```css @container style(--theme: dark) { .card { background: black; } } ```

问题在于：样式查询的浏览器支持比`:has()`更晚，Firefox 至今未完全实现。如果团队为了"逻辑系统"同时引入两者，兼容性矩阵会变得非常复杂。

风险三：调试认知负担

`:has()`选择器的匹配逻辑是"反向"的——你看到样式生效，需要反向追溯是哪个子元素触发了条件。Chrome 的 Elements 面板会标注`:has()`匹配结果，但复杂页面中，嵌套的`:has()`和`:not()`组合会让调试变得像解谜。

对比传统 class 方案：`.card--with-image`一目了然，而`.card:has(> figure > img:not([src=""]))`需要逐层解析。

我的判断：分阶段采纳，守住三条红线

`:has()`确实是 CSS 架构的重要进化，但"替代 JavaScript"的说法过于绝对。基于原文信息，我的建议是：

红线一：交互复杂度分级

纯视觉反馈（边框变色、布局调整）优先用`:has()`；需要数据传递或状态持久化的场景（如表单提交前的最终校验）仍用 JS。原文的表单验证示例其实只覆盖了"即时视觉反馈"层，完整的错误提示和提交拦截仍需配合脚本。

红线二：性能预算前置

在关键渲染路径上避免`:has()`——首屏内容、Above the fold 的组件用传统 class 方案保证确定性。`:has()`更适合延迟加载的模块或用户交互后的次级反馈。

红线三：团队能力匹配

如果团队还在用 Sass 嵌套写 BEM，直接跳转到`:has()` + 样式查询的组合会导致维护灾难。建议先在小范围组件（如设计系统的卡片、按钮）试点，建立代码审查时的性能检查清单，再逐步扩展。

最后一点常被忽略：`:has()`的真正价值可能不在"替代 JS"，而在"减少 class 的滥用"。过去我们用`is-active`、`has-image`、`is-empty`等类名传递状态，现在部分可以内隐到 CSS 逻辑中。这让 HTML 更语义化，也让样式和结构的耦合方式发生质变。

这不是非黑即白的工具选择，而是前端架构哲学的微调——从"显式标记一切"走向"声明式推断"。

你的项目里`:has()`用到了什么程度？是已经大规模落地，还在观望兼容性，或者踩过性能坑？评论区聊聊实际经验，比文档更有参考价值。