:has()并非真正反向选择父元素，而是以祖先元素为选择主体、基于其内部子元素存在性进行条件匹配；必须绑定具体祖先选择器（如div:has(.active)）才生效，单独使用:has()无效。
为什么直接用 :has() 无法“反向选中父元素”
:has() 确实支持“子元素存在时样式父元素”，但它不是真正意义上的“反向查找”，而是 CSS 选择器的**关系匹配机制**——它让父（或祖先）元素成为**被样式化的主体**，前提是其内部满足某个条件。你不能用它选中“某个具体父节点并修改它”，只能写成「当某元素包含符合条件的后代时，给这个元素加样式」。
常见误解是以为能像 JS 的 el.parentElement 那样跳转到父级 DOM 节点操作；实际它只是语法糖，底层仍是自上而下的选择逻辑。
:has() 必须配合祖先选择器使用才生效
单独写 :has(.active) 没有意义，必须绑定在某个祖先元素上，比如 div:has(> .active) 或 article:has(p em)。浏览器会遍历每个 div，检查它是否含有直接子元素 .active，满足则应用样式。
- ✅ 正确：
ul:has(li.active) { border: 2px solid blue; }—— 当任意li有active类时，给整个ul加边框 - ❌ 错误：
:has(li.active) { ... }—— 无锚点，CSS 无效（现代浏览器会直接忽略整条规则） - ⚠️ 注意：
div:has(.btn):has(.form)表示同一个div内**同时存在**两类元素，不是“或”关系
嵌套层级与性能影响很现实
:has() 的计算成本比普通选择器高，尤其在深层嵌套或动态内容多的页面。浏览器需对每个候选祖先节点执行子树遍历，若写成 body:has(.modal.open)，等于每次重排都要扫描整个 DOM 树。
- 推荐限定范围：
.card:has(.card__footer button:disabled)比泛化写法更可控 - 避免通配符：
*:has(.loading)是性能杀手，不要用 - 某些场景下，用 JS 切换 class 更轻量，例如监听子元素状态变化后手动给父元素加
has-loading类 - 当前 Safari 15.4+、Chrome 105+、Firefox 121+ 支持，但旧版 Edge（
替代方案：什么时候不该硬上 :has()
如果目标是“根据子元素状态动态控制父容器行为”，得先判断是否真需要纯 CSS 解决。很多看似适合 :has() 的场景，其实隐藏着响应及时性或逻辑分支问题。
- 子元素是异步加载的？
:has()不会触发重绘，除非 DOM 变化被浏览器感知（如插入/移除节点），单纯 JS 改 class 可能不够 - 需要多个条件组合判断（如“A 存在且 B 不存在且 C 的 data-status=error”）？
:has()表达力有限，易写成超长选择器，可读性骤降 - 要兼容 IE 或低端安卓设备？别用，fallback 方案（如服务端渲染 class、JS 注入）更稳
真正要用好 :has()，得把它当成一个带条件的“祖先标记开关”，而不是父元素查询 API。它的价值在于减少 JS 干预，但边界很清晰——不处理动态数据流，不替代状态管理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
