:has() 在旧版浏览器（Chrome 105前、Firefox 119前、Safari 15.4前）不支持，会忽略整条规则；需用 @supports 检测、PostCSS 回退或 JS 辅助，并注意子树匹配限制与性能开销。
为什么 :has() 在某些浏览器里完全不生效？
因为 :has() 是较新的 CSS 选择器，Chrome 105+、Firefox 119+ 和 Safari 15.4+ 才支持，旧版浏览器（尤其是 Safari 15.3 及更早）会直接忽略整条规则。如果你在本地测试时样式没反应，先检查浏览器版本和开发者工具是否报「invalid selector」警告——那大概率是兼容性问题。
实操建议：
- 用
@supports selector(:has(*)) { ... }包裹关键样式，避免降级时出错 - 在构建流程中加 PostCSS 插件（如
postcss-has-pseudo）做简单回退，但注意它无法真正模拟父级逻辑，只能降级为 class 切换 - 不要依赖
:has()做核心交互逻辑，比如表单必填校验的视觉反馈，应配合 JS 补充 class 控制
:has() 能匹配哪些子元素状态？
它支持任意合法的选择器，包括伪类、属性选择器、甚至组合器，但不能包含伪元素（::before 等）或 :has() 自身嵌套（目前规范禁止递归）。
常见可用场景：
立即学习“前端免费学习笔记（深入）”；
-
div:has(input:focus)—— 输入框获得焦点时高亮整个容器 -
li:has(> a.active)—— 直接子链接有active类时给列表项加边框 -
form:has(:invalid)—— 表单内任意字段校验失败时整体标红 -
button:has(+ .tooltip)—— 后续兄弟元素是 tooltip 时调整按钮 padding
注意：:has(.class:hover) 在鼠标未悬停时不会触发重绘，实际表现符合预期；但 :has(input:valid) 这类动态状态依赖浏览器实时校验，部分老式自定义 input 可能不触发 :valid。
为什么写了 :has() 却没改变父元素样式？
最常见原因是选择器层级或 DOM 结构不匹配。CSS 中 :has() 的参数是相对于当前元素的子树查找，不是全局搜索。
容易踩的坑：
-
section:has(div p)只匹配「section内存在div的后代是p」，而不是「section下某div里有p」——两者语义一致，但写成section:has(p)就错了，因为p可能在其他嵌套层级 - 使用
>时必须严格父子关系：ul:has(> li:last-child)不会匹配ul，除非最后一个li是其直接子元素 -
:has()不支持跨 shadow DOM，Web Component 内部状态无法被外部:has()捕获 - React/Vue 等框架若用
display: none或条件渲染移除子元素，:has()会立即失效——这和 JS 的element.hidden不同，后者仍保留在 DOM 中
性能要注意什么？
:has() 是 CSS 中少有的「需要遍历子树」的选择器，浏览器必须对每个候选父元素执行子节点匹配，复杂选择器会显著拖慢渲染。
优化建议：
- 避免写
:has(*)或:has([data-*])这类宽泛匹配，优先用明确标签或 class - 不要在高频重绘区域（如滚动容器、动画元素）上大量使用，例如
.item:has(.badge)配合 100 个.item列表，可能引发卡顿 - Chrome DevTools 的「Rendering」面板可勾选「Paint flashing」观察是否因
:has()导致频繁重绘 - 若发现性能问题，用 JS 监听子元素状态变更后 toggle class，比纯 CSS 更可控
真正难的是平衡语义清晰和运行效率——写起来很爽的 article:has(> h2, > h3)，可能比加一个 has-heading class 多花 3ms 渲染时间，而这点时间在低端设备上就是肉眼可见的延迟。
