:has()不能替代媒体查询，但能补足内容驱动型响应，如子元素数量、状态、存在性变化时的布局切换；它比js更可靠、声明式、首屏一致，但需注意html结构干净度和浏览器兼容性。
直接说结论：:has() 不能替代媒体查询，但能补足它无法处理的“内容驱动型响应”——比如子元素数量、状态、存在性变化时的布局切换，这类逻辑用 JS 维护成本高、易漏、首屏不一致。
怎么用 :has() 实现“3 项以上用 grid，否则 flex”
传统 JS 方案要监听 appendChild、removeChild，还要预处理文本节点；:has() 一行 CSS 就能声明式响应：
-
.list:has(> .item:nth-child(4))→ 至少 4 项，触发grid-template-columns: repeat(3, 1fr) -
.list:has(> .item:nth-child(3)):not(:has(> .item:nth-child(4)))→ 恰好 3 项，用两列flex - 别用
:nth-last-child()，它会被换行符、注释、空格干扰；:nth-child(n)是正向锚点，更稳定 - 如果 HTML 里有换行或注释，
.item可能是:nth-child(2)而不是1—— 建议用display: contents包裹或服务端预处理
:has() 在表单验证中为什么比 JS class 切换更可靠
JS 方案常在 input 输入后忘记更新 class，或 SSR 首屏没 class 导致 layout shift；:has() 是浏览器原生重匹配机制：
-
label:has(input:not(:placeholder-shown):valid)→ 有值且校验通过才生效，比value!=" "可靠（value属性不随输入实时更新） -
.form-group:has(.error-message)→ 错误提示 DOM 插入即生效，无需手动调用updateFormState() -
.accordion-header:has(+ .accordion-content[open])→ 依赖原生[open]属性，自定义data-open必须靠 JS 同步写入 DOM 才能被 :has() 捕获
为什么必须用 @supports selector() 包裹 :has()
@supports :has() 无效，这是常见误写；真正有效的检测方式只有：
-
@supports selector(:has(*))—— 唯一被所有支持浏览器认可的语法 - Chrome 105+、Firefox 121+、Safari 15.4+ 稳定支持，但 Safari ≤15.3 完全不支持，15.4–16.3 对
:has(.x + .y)等兄弟选择器有 bug - 项目需兼容旧 Safari？必须降级为 JS fallback 或预设 class，不能只靠
@supports掩耳盗铃 - 哪怕只多一个换行符，
:has(> .item)就可能失效——因为那个换行是 text node，.item实际是:nth-child(2)
最常被忽略的不是语法，而是 HTML 结构的“干净度”：:has() 匹配的是真实 DOM 树，不是你想象中的结构。空格、换行、注释都会让 :nth-child() 偏移，进而让整个规则静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
