:has(> .active) 因浏览器兼容性差（Chrome 105+/Safari 15.4+才支持，Firefox需手动开启，X5/旧WebView完全不识别）且无降级提示，在多数项目中直接失效；实际应优先用服务端加class或MutationObserver监听替代。
:has(> .active) 能选中含直接子元素 .active 的父元素，但实际可用性极低——它在 Chrome 105+、Edge 105+、Safari 15.4+ 中才支持，Firefox 需手动开启 layout.css.has-selector.enabled，而微信 X5 内核、企业内网 WebView（常见于 Chrome 70–90）、旧版 Electron 等环境完全不识别该语法，且无任何降级提示或报错。
为什么 :has(> .active) 在多数项目里直接失效
浏览器对 :has() 的支持不是“部分支持”，而是“非全有即全无”。只要运行环境不满足最低版本要求，整条规则会被浏览器静默丢弃。例如：
- 你在内部管理系统中写
.nav:has(> .active) { background: #007bff; }，用户用 Chrome 102 打开，样式不会生效，DevTools 里连这条规则都看不到 - 微信内嵌页（X5 内核 v4.3.x，对应 Chromium 77）下，
:has()声明被彻底忽略，哪怕只用最简单的div:has(p) - CanIUse 显示“85% 全球支持”是加权平均值，B 端系统、银行 App、政务平台的真实覆盖率常低于 40%
:has(> .active) 和 :has(.active) 的关键区别
前者只匹配 .active 是**直接子元素**的父节点，后者匹配任意后代；但这个语义差异在工程中几乎无法兑现：
-
:has(> .active)在 Safari 15.4–16.3 中存在 bug：当父元素是<ul></ul>且子元素为<li class="active">时，部分版本会误判为不匹配 - Chrome 对
>的解析更严格，若中间有注释节点或文本节点（哪怕只是换行符），>关系即断裂，导致选择失败 - 性能上，
:has(> .active)比:has(.active)略快，但差距微乎其微（DevTools Rendering 面板测得约 0.3ms），不值得为这点优化牺牲兼容性
没 :has() 时怎么让父元素响应 .active 状态
优先按成本与稳定性排序：
立即学习“前端免费学习笔记（深入）”；
- 后端/模板层直接输出语义 class：
<nav class="nav nav--has-active"></nav>，零 JS、零兼容风险、服务端可缓存 - 前端用
MutationObserver监听子节点变动，仅在.active出现/消失时 toggle 父元素 class，比轮询高效，且兼容 IE11+ - 如果必须用 CSS 驱动，改用属性选择器模拟状态：
.nav[data-has-active="true"]，由 JS 控制dataset，CSS 规则保持纯净
真要用 :has(> .active)，必须避开的坑
即使目标环境明确支持，也容易踩进渲染陷阱：
- 不要嵌套
:has()：:has(> :has(.trigger))在 Safari 16+ 中会崩溃或卡死主线程 - 避免与
:not()组合：:has(> :not(.hidden))在部分 Edge 版本中被整个忽略 - 别在
@media内重复声明：@media (min-width: 768px) { .nav:has(> .active) { ... } }，某些 Safari 15.x 会丢弃整个媒体查询块 - 伪元素无效：
:has(> .active::before)不合法，::before不是真实 DOM 节点，:has()只匹配可遍历的元素节点
真正需要 :has(> .active) 的场景极少——通常是富文本卡片、第三方插件注入的不可控 DOM、或强制禁用 JS 的审查环境。其他情况，加一个 class 或一行 MutationObserver 更稳、更快、更可测。
