:has()不是真正父选择器，而是CSS中唯一原生实现“子变→父响应”的声明式方案；它匹配祖先元素而非仅直接父级，需显式指定目标选择器、依赖现代浏览器支持（Chrome105+/Safari15.4+），且父元素不可被display:none隐藏。
:has() 不是真正的父级选择器，但它是在 CSS 层面唯一能实现“子变 → 父响应”的原生方案。所有其他所谓“父选择”手段（比如 JS 操作 class、结构预设、属性标记）都绕开了样式层本身，而 :has() 是纯声明式、零 JS、不改 DOM 的向上匹配能力。
为什么浏览器厂商坚持叫它“父选择器”？
因为它的行为逻辑完全对标开发者最常写的伪需求：“当某个子元素存在/满足条件时，给它的父容器加样式”。虽然技术上它匹配的是祖先元素（不限于直接父级），但绝大多数真实场景中，你写的 div:has(input) 或 label:has(input:checked) 所指的“父”，就是语义上那个包裹控件的容器——它解决了过去必须靠 JS 注入 form--has-error 这类 class 的痛点。
关键点在于：:has() 的括号内是条件，外面的选择器才是目标；它不改变 DOM，也不触发重排，只在样式计算阶段做一次存在性判断。
:has() 什么时候会完全失效？
不是语法写错，而是环境不支持或结构被“屏蔽”：
立即学习“前端免费学习笔记（深入）”；
- Chrome
- 父元素设置了
display: none或visibility: hidden——:has()不匹配不可见元素 - 子元素是通过
contenteditable或富文本粘贴动态插入，且未触发 layout —— 初始渲染时可能漏判 - 用了不被允许的内部选择器，例如
:has(::before)、:has(:focus)（部分 Safari 版本）、:has(.x + .y)（Safari 15.4–16.3 不稳定）
比 :focus-within 和 :invalid 强在哪？
它不依赖元素是否可聚焦、是否表单控件、是否暴露原生状态。你能用它干三件它们做不到的事：
- 响应
<img src="">的空 src 状态：.card:has(img:not([src])) - 识别富文本中随机插入的
<span class="highlight">并高亮整段：p:has(span.highlight) - 基于兄弟关系控制前一个标题样式：
h2:has(+ .section-content[open])（配合<details>）
这些场景里，:focus-within 要求元素可聚焦，:invalid 只对表单有效，而 :has() 只要 DOM 存在、选择器合法、浏览器支持，就能生效。
真正难处理的边界情况是什么？
不是语法或兼容性问题，而是性能隐忧和结构耦合：
- 写
section:has(div ul li a.active)这种深层后代链，Chrome 会多花 4–6ms 做样式重计算，尤其在长列表滚动时可见卡顿 - 依赖
:has(> .trigger)却忘了父元素实际是div > article > .trigger，结果匹配失败 —— 它不自动“向上找最近父级”，必须显式写出层级或接受任意后代 - 在 CSS-in-JS 库（如 Emotion）中默认被剥离，除非手动开启
css={...}的dangerouslySetInnerHTML等等兜底开关
所以它不是“终极万能解”，而是“现代桌面环境里，最接近理想的轻量声明式反向控制工具”——用之前，先确认你的用户真在 Chrome 105+ 或 Safari 15.4+ 里，且那个父容器，确实没被 display:none 掩埋。
