:has()不能直接给父元素加背景色或边框，因其仅选择元素而不触发重布局，父容器尺寸早已固定，样式虽生效但常被子元素遮盖或未适配；需配合display: contents、position: relative等显式建立层叠上下文，或改用JS监听变更。
为什么:has()不能直接给父元素加背景色或边框
因为:has()只是选择器，它本身不改变渲染行为，只决定“谁被选中”；但浏览器在布局阶段（layout）早已完成父容器尺寸计算，此时再通过:has()匹配并设置background或border，不会触发父容器重新测量——所以看起来“没反应”，其实是样式生效了，但视觉上被子元素遮盖或尺寸没适配。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
:has()配合display: contents或position: relative显式建立层叠上下文，避免子元素溢出干扰 - 若需动态撑开父容器，优先改用 JS 监听子节点变化后手动加 class，而不是纯 CSS 驱动
- 注意
:has(.child:hover)这类写法在滚动或快速移入时可能因重绘时机导致闪烁，应搭配will-change: transform做提示
:has()嵌套层级超过 2 层就失效的常见原因
不是语法限制，而是选择器可读性与浏览器实现的权衡。Chromium 110+ 和 Safari 15.4+ 支持多层:has()，但一旦出现:has(.a > :has(.b > :has(.c)))这种写法，部分旧版 Safari 会静默忽略整个规则，连带同条 CSS 中其他声明也不生效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 拆成多个独立规则，比如先写
.a:has(.b)，再在它内部用.b:has(.c)，用 class 分层承接状态 - 避免在
:has()里用通用兄弟选择器~或相邻兄弟+，它们在嵌套:has()中兼容性更差 - 用
@supports selector(:has(*))包裹整段逻辑，并为不支持环境提供data-属性 fallback
用:has()实现“有滚动条才显示右阴影”的真实场景
这个需求很典型：容器内容超长时，需要在右侧加一层渐变阴影暗示可滚动，但又不能靠 JS 持续监听scrollWidth > clientWidth——太耗性能。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给容器设
overflow-x: auto，并在其子元素上放一个固定宽度的“锚点”元素：<div class="scroller"><div class="anchor" style="width: 100.1%;"></div></div> - 用
.scroller:has(.anchor)匹配，再通过background-image: linear-gradient(...)叠加在::after伪元素上 - 注意
width: 100.1%必须带小数点，整数如101%在某些缩放比例下会被四舍五入回100%，导致:has()不触发
和 Flex/Grid 布局混用时:has()的尺寸陷阱
当父容器是display: grid且设置了grid-template-columns: 1fr 2fr，再写.grid:has(.item:last-child)去加 margin，很可能发现最后一项根本没被识别——因为 Grid 项的 DOM 顺序和渲染顺序可能不一致（尤其用了order或grid-area）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
:has()匹配结构特征（如:has(> [data-role="footer"])），而非位置特征（:has(:last-child)） - 如果必须依赖位置，先确保子元素没有
order、grid-row等重排属性，或改用display: contents临时剥离布局影响 - 在 Grid 容器上使用
:has()时，记得检查grid-auto-flow是否为row，否则:has(.item)可能意外匹配到空轨道生成的隐式项
:has()，而是判断什么时候它不该出现——比如要响应内容高度变化、跨 iframe 边界、或需要服务端渲染支持时，就得老老实实用 JS 或服务端逻辑兜底。 
