现代浏览器（chrome 105+、safari 15.4+、firefox 121+）已默认支持 :has()，但旧版本会静默忽略整条规则；需用 css.supports('selector(:has(*))') 实测验证，且注意语法限制、性能开销及 ssr 不生效等问题。
直接用 :has() 选父元素，现在能行但得看浏览器版本
Chrome 105+、Safari 15.4+、Firefox 121+ 已默认启用 :has()，不用开 flag，也不用等未来。但如果你的用户里还有 Chrome 104 或更早、iOS 15.3 及以下、Firefox 102 及以下的访问量，这条规则会静默失效——不是报错，是整条 CSS 被忽略，开发者工具里都看不到划掉的样式。
验证是否真支持，别信 UA 字符串，直接在控制台运行：CSS.supports('selector(:has(*))')，返回 true 才算数。
- 旧版构建工具（如 cssnano 默认配置）可能直接删掉含
:has()的整条规则，上线前务必检查产物 CSS - Next.js、Vue CLI 等 SSR 框架中，
:has()在服务端不生效，首屏渲染时父元素不会带对应样式 -
@supports selector(:has())写法不保险——部分旧 Chromium 会误判为支持，实际不渲染
:has() 语法写错最常导致“看起来写了却没反应”
它只允许出现在选择器开头，且必须紧贴父选择器，不能嵌套、不能跟在关系符后面。比如 .card:has(.btn:hover) 合法，但 .card > :has(.btn) 或 div:has(.a):has(.b) 都非法，浏览器直接跳过整条规则。
- 子元素必须是父元素的**后代**（含嵌套多层），不是兄弟或 for 关联的 label–input 这种逻辑关系
-
:has(.child)匹配任意后代，要限定层级就得加关系符：:has(> .child)（仅直系）、:has(+ .sibling)（后紧邻）、:has(~ .later)（后续任意） - W3C 验证器目前对
:has(.cls)报错，但所有现代浏览器都支持；稳妥起见可统一写成:has( .cls)（括号后空格） - 禁止在
:has()内部使用伪元素（::before）、状态伪类（:hover、:focus、:active）——:has(input:focus)合法，但:has(label:hover)不合法（hover 是运行时状态，不可用于匹配逻辑）
性能和可维护性比语法更值得警惕
:has() 不是“查一次就完事”，浏览器要为每个候选父元素遍历其全部后代 DOM 节点来判断条件是否满足。DOM 深度大、节点多时，重排重绘明显变慢。
- 在含 200+ 个
<li>的列表上写ul:has(li.active)，滚动帧率实测下降超 30% - 避免
:has(:has())嵌套，这是双重全量扫描，等价于强制遍历整个子树 - 高频交互区域（如 hover、输入框 focus）慎用；改用 class 切换 +
:hover组合更稳 - 用更具体的选择器缩小候选集：比如
.nav-menu:has(> .item.active)比nav:has(.item.active)快得多
真正难的不是怎么写，而是该不该用
多数业务场景下，几行 JS 监听 + class 切换，比押注 :has() 兼容性和性能更可靠。尤其当子元素是动态插入、需 SSR 支持、或涉及可访问性状态（如 aria-invalid）时，JS 补位几乎是唯一可控路径。
- 表单校验：监听
input的input或blur事件，用setCustomValidity()+closest()控制父容器 class - 动态内容：用
MutationObserver监听新增节点，比等:has()自动响应时机更精准 - 关键 UI（如导航高亮、错误提示）别依赖
:has()；降级策略不是“多写一条备用规则”，而是结构前置（如服务端提前加has-error类）
它省了 CSS 行数，但换来的是兼容性清单、测试覆盖、以及某天发现老用户界面突然错乱的排查成本——这个权衡点，往往在项目上线前最后一刻才被意识到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
