Chrome 105+、Edge 110+、Safari 15.4+（仅 macOS）和Firefox 121+（需手动开启）支持:has(> img)，但旧版浏览器会忽略该选择器且不报错；它仅匹配直接子代img，不支持链式或后代选择，且受图片异步加载影响，性能随条件复杂度上升而下降。
Chrome 105+ 才能用 :has(> img) 控制父级样式
这个选择器不是所有浏览器都支持，目前只有 Chrome 105+、Edge 110+、Safari 15.4+（仅 macOS）和 Firefox 121+（需手动开启 layout.css.has-selector.enabled）。如果你的用户里还有大量旧版 Chrome 或国内双核浏览器（实际用的是旧版 Trident/WebKit 内核），:has() 会直接被忽略——样式不生效，且不会报错。
常见错误现象：div:has(> img) { opacity: 0.9; } 在 Safari 15.3 或 Chrome 104 下完全没反应，开发者工具里也看不到匹配项。
- 上线前务必检查目标用户浏览器分布，别只在自己最新 Chrome 里测
- 可以用
@supports selector(:has(> img))做渐进增强，但注意：IE 和老 Edge 完全不识别@supports里的selector()函数，会整个块跳过 - 如果必须兼容，得回退到 JS 监听
img加载完成再加 class，或用div img:first-child+ 负 margin / absolute 定位模拟“父级响应”
:has(> img) 只匹配**直接子代**，不是任意后代
很多人写成 div:has(img) 想匹配内部有 <img> 的任意位置，结果失效。因为 :has() 里的 > 是关键：它限定必须是 **紧邻子元素**，不能是孙子、曾孙。
使用场景举例：你只想给「封面图单独占一行」的卡片容器加阴影，而不是所有含图片的模块（比如图文混排的正文区域）。
立即学习“前端免费学习笔记（深入）”；
-
article:has(> img)✅ 匹配<article><img></article> -
article:has(img)❌ Safari 15.4+ 支持，但 Chrome 105–117 不支持无>的写法（会解析失败） -
section:has(> div > img)❌:has()不支持链式子代，这种写法无效
图片加载延迟会导致 :has(> img) 初始不匹配
<img src="..."> 是异步加载的，DOM 渲染时 <img> 标签虽已存在，但浏览器还没确认它是否真能加载出内容（尤其是懒加载或网络慢时）。此时 :has(> img) 可能判定为“无匹配”，父级样式不触发。
典型表现：首屏卡片刚出来时没特效，等图片加载完才突然淡入/缩放——用户体验割裂。
- 加
loading="eager"强制预加载（慎用，影响性能） - 用
<img>的decoding="async"或fetchpriority="high"提升优先级 - 更稳的做法：服务端渲染时就判断是否有图，输出对应 class；或用
img.addEventListener('load', ...)补触发
别在 :has() 里写太复杂的条件，性能会明显下降
浏览器要为每个候选父元素遍历其子节点来验证条件，嵌套越深、条件越多，重排重绘开销越大。实测在 200+ 个 div:has(> img) 同时存在时，滚动帧率可掉到 30fps 以下。
参数差异：单条件 :has(> img) 和双条件 :has(> img, > svg) 性能差距不大，但 :has(> img[src*='banner']) 就容易卡——属性选择器触发更频繁的 DOM 属性扫描。
- 优先用简单标签匹配，避免带属性、伪类或组合选择器
- 如果只是想区分“有图”和“无图”，不如用
div[data-has-img]+ JS 初始化一次 - 移动端尤其敏感，iOS Safari 对
:has()的优化远不如桌面端
:has(> img)，得盯着三件事：浏览器支持边界、DOM 结构是否真满足“直接子代”、图片资源是否在样式计算前就位——漏掉任何一点，效果就断在用户眼前。 
