@supports 不能检测伪类是否可用，只能判断语法解析能力；正确写法是 @supports selector(:hover)，而非 @supports (:hover)；它仅表明浏览器能安全解析选择器，不保证行为一致或语义合理。
@supports 不能直接检测伪类是否“可用”，更不能用它模拟伪类行为——它只判断语法能否被解析，不保证渲染或交互逻辑生效。
为什么 @supports (:hover) 永远不成立
伪类（如 :hover、:focus-visible、:has()）不是 CSS 属性，而是选择器的一部分。@supports 的括号内必须是「属性: 值」对，而 :hover 不符合该语法结构。浏览器遇到 @supports (:hover) 会直接忽略整条规则——不是返回 false，是压根不识别。
- ✅ 正确检测选择器能力：用
@supports selector(:hover)（注意函数调用语法） - ❌ 错误写法：
@supports (:hover)、@supports (hover: hover)、@supports hover - ⚠️ 注意：
selector(:hover)在所有主流浏览器中都返回true（哪怕设备无指针），它只测语法支持，不测语义合理性
@supports selector() 的真实支持边界
这个函数不是“有没有这个伪类”的开关，而是“浏览器能不能安全地解析并跳过不认识的选择器”的能力标志。它的支持度断层极明显：
- Safari ≤16.3：完全忽略
@supports selector(...)整条规则（静默失败，不进块也不报错） - Chrome 83+ / Firefox 69+：支持基础形式，但复杂嵌套（如
:has(+ div, ~ p)）可能解析失败 -
selector(*)是最安全的兜底探测，但旧版 Safari 连这个也跳过——不能用来“确认 selector() 是否可用” - 检测
:has()必须分两步：@supports selector(:has(*))+@supports selector(article:has(> h2))，后者验证实际使用场景
用 @supports 检测伪类时最容易踩的坑
你以为在做兼容性降级，其实只是在测试浏览器的 parser 能力。很多“检测通过却行为异常”的问题，根源在这里：
-
@supports selector(:focus-visible)返回true，但 Safari 16.4–17.2 对:focus-visible的触发逻辑仍和 Chrome 不一致（比如键盘操作后不立即生效） -
@supports not selector(:has())在 Safari 16.3 中会意外通过——因为整个selector()语法不被识别，not作用于无效表达式，结果为true - 不要单独依赖
selector()做功能开关；关键交互点必须搭配 class 降级（例如给按钮加.has-hover类，再用 JS 监听mouseenter补充行为） - 检测
:is()或:where()时，值必须合法：@supports selector(:is(h1, h2))✅，@supports selector(:is())❌（空参数不被解析）
真正需要关注的不是“支持与否”，而是“是否可靠”
一个伪类即使能被 @supports selector() 捕获，也不代表它在所有上下文里都按预期工作。比如 :has() 在 display: contents 容器中失效，:focus-visible 在 iOS Safari 中默认关闭且无法用 CSS 启用。这时候，@supports 给出的只是“语法通行证”，不是“行为担保书”。
最务实的做法是：把 @supports selector() 当作第一道过滤器，再用最小化 DOM 测试（比如插入临时元素 + matches() 调用）验证运行时行为，最后为不可控场景预留 class 驱动的 fallback。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
