@supports selector() 并非万能选择器探测器，仅 Safari 16.4+、Chrome 83+、Firefox 69+ 支持，但旧版 Safari（如16.3）完全忽略该规则；检测 :has() 需分层验证，且需配合版本判断与 class 降级；not selector() 易误判，应优先用属性检测兜底。
@supports selector() 不是万能的“选择器支持探测器”，它只在特定浏览器版本中可用，且对复杂选择器的支持存在明显断层。直接写 @supports selector(:has()) 在 Safari 16.3 及更早版本里会被完全忽略——不是返回 false，而是压根不解析这条规则。
selector() 函数本身有明确的浏览器支持门槛
这个函数从 Safari 16.4 才开始被真正识别；Chrome 和 Firefox 虽然早在 83/69 版本就支持了，但早期实现并不稳定。这意味着：
- 你在 Safari 16.3 测试时看到样式没生效，不是代码写错了，而是浏览器根本没进到
@supports的判断逻辑里 -
@supports selector(*)这类“兜底测试”在旧版 Safari 中也会静默失败，不能用来做 fallback 检测 - MDN 明确标注
selector()是 “baseline widely available”，但这个“广泛可用”是相对的——它不包括任何低于 Safari 16.4 的 iOS/macOS 用户
检测 :has() 这类新伪类必须组合版本判断
:has() 本身在 Safari 中是分阶段支持的：15.4 开始支持简单形式（如 :has(> img)），但复杂嵌套（:has(+ div, ~ p)）仍会失效。而 @supports selector(:has()) 在 Safari 16.4+ 才能正确返回 true/false。所以实际使用时得这样处理：
- 先用
@supports selector(:has(*))做基础存在性判断（* 是最安全的子选择器） - 再叠加具体用法测试，比如
@supports selector(article:has(> h2))，避免把未实现的语法当已支持 - 永远准备 fallback：即使
@supports返回 true，Safari 对:has()的解析深度仍可能不如 Chrome，建议在关键布局中保留class驱动的降级方案
not selector() 容易误判，慎用
@supports not selector(:focus-visible) 这类写法在部分旧引擎中会意外通过——因为整个 selector() 语法不被识别，导致 not 作用于一个无效表达式，结果变成“true”。这不是逻辑错误，而是解析层面的兼容性断裂。更稳妥的方式是：
立即学习“前端免费学习笔记（深入）”；
- 优先用属性检测兜底，例如
@supports (focus-ring: auto)辅助判断:focus-visible环境 - 避免单独依赖
not selector()做功能开关，它更适合用于排除已知不支持的极端情况 - 如果必须用，加一层
@supports selector(span)前置校验，确认浏览器至少具备selector()基础能力
真正棘手的不是语法怎么写，而是 Safari 对 selector() 和它所检测的选择器（比如 :has()、:target-within）实行了两套独立的兼容策略——前者是规则解析能力，后者是渲染引擎实现。这两者在不同版本间错位严重，必须分开验证，不能假设“支持函数就支持所有参数”。
