Chrome 105+、Safari 15.4+、Firefox 121+已默认支持:has()伪类，可实现子元素反选父元素，需用>、+、~等关系符精确控制层级，且不可用于选择器中间或与伪元素连用。
Chrome 105+ 和 Safari 15.4+ 可以直接用 :has() 选父级
截至 2026 年，:has() 已在 Chrome 105+（2022 年 9 月起）、Safari 15.4+（2022 年 3 月起）、Firefox 121+（2023 年 12 月起）中默认启用，无需 flag。它能真正实现“从子反选父”，比如：a.active:has(> span.highlight) 匹配的是 a 元素本身，前提是它的直接子元素中有 span.highlight。
常见误用是写成 div:has(.child) { ... } 却期望它只在 .child 是直接子元素时生效——其实它默认匹配任意后代，要精确控制层级得加关系符：
-
div:has(> .child)：仅当.child是直接子元素时触发 -
div:has(+ .sibling)：仅当后面紧邻一个.sibling元素时触发 -
div:has(~ .any-later)：只要后面有任意一个.any-later就触发
注意：:has() 不能出现在选择器开头以外的位置（比如 .parent :has(.child) 是非法语法），也不能和伪元素连用（如 :has(.child)::before 不合法）。
IE 或旧版 Chrome/Firefox 中 :has() 不可用，必须降级处理
如果项目需兼容 IE、Chrome :has() 会静默失效——样式完全不应用，开发者工具里也看不到划掉的规则，容易误判为选择器写错。
立即学习“前端免费学习笔记（深入）”；
安全降级策略不是“多写一条备用规则”，而是结构前置或 JS 补位：
- 把状态类提前加到父元素上，比如点击
span时，用 JS 同时给其parentElement加.has-highlight，再写.has-highlight { ... } - 避免在关键路径（如导航高亮、表单校验）中依赖
:has()，优先用input:focus + label这类已广泛支持的兄弟选择器替代 - 用
@supports selector(:has(*))做特性检测，仅在支持时启用复杂逻辑，否则回退到简化样式
:has() 的性能开销比想象中大，别滥用在高频更新区域
:has() 要求浏览器对每个候选父元素遍历其全部后代来判断条件，DOM 深度或宽度大时会明显拖慢重排重绘。实测在含 200+ 个 li 的列表中对每个 ul:has(li.active) 计算，滚动帧率可下降 30% 以上。
优化建议：
- 限制作用范围：用更具体的选择器缩小候选集，比如
.nav-menu:has(> .item.active)比nav:has(.item.active)快得多 - 避免嵌套
:has()：section:has(div:has(p))是双重遍历，几乎等价于强制全量扫描 - 动画/悬停场景慎用：鼠标移入时触发
:has()计算，可能造成卡顿；改用:hover配合 class 切换更稳
SCSS 编译不生成 :has()，别指望预处理器“帮你兼容”
有人以为用 SCSS 写 &:has(.child) { ... }，编译后就能自动降级——不会。:has() 是原生 CSS 特性，SCSS 只做字符串替换，编译结果就是字面的 parent:has(.child)。它既不会添加前缀，也不会生成后备规则。
如果你依赖构建工具链做兼容处理，得明确配置：
- PostCSS 插件如
postcss-has-pseudo可将简单:has()转为 JS 补丁，但仅支持基础语法，复杂选择器会报错 - Vite / Webpack 的
cssnano默认会删掉无法识别的伪类，需关闭discardUnused防止误删 - 真正可靠的兼容方案仍是“JS 控制 class + CSS 控制样式”，而不是寄希望于编译时魔法
最后提醒一句：:has() 解决的是“我能选父级吗”这个长期痛点，但它不是银弹。很多你以为需要父选择器的场景，其实只是 HTML 结构没对齐语义——先问自己：这个状态，真的不该由父元素自己携带 class 吗？
