@supports 不能检测选择器支持性，仅支持属性/值检测；selector() 语法支持不均，IE/Safari/Firefox旧版静默忽略；可行方案为正向标记、服务端注入类名、轻量JS补位。
@supports 不能检测选择器是否被支持，这是最常踩的坑。它只认属性和值，比如 display: grid 或 color: oklch(0% 0 0)；写 @supports selector(:has(a)) 在 Chrome 110+ 才解析，IE、Safari ≤15.3、Firefox ≤108 全部静默忽略整条规则——连降级逻辑都进不去。
为什么 @supports selector() 不是通用解法
这个语法是 CSS Selectors Level 4 的扩展，浏览器支持极不均衡：@supports selector(:has(a)) 在 Safari 15.4+ 和 Firefox 121+ 才稳定可用，而 IE11 完全不认识该关键字，连语法解析都失败。更关键的是，@supports 规则本身在不支持它的浏览器中会被整块跳过，但你没法靠它触发 JS 或 fallback 样式。它不是“开关”，只是“过滤器”——只对已支持该检测语法的浏览器生效。
- Chrome 110+：支持
selector()检测，但仅限部分伪类（如:has、:is） - Safari 15.4–16.3：
:has()可用，但selector(:not(:has()))偶发失效 - Firefox ≤120：完全不识别
selector()，整条@supports规则被丢弃 - IE11：不解析
@supports任何变体，现代样式和检测逻辑全部丢失
真正可行的选择器兼容方案只有三类
必须放弃“用 CSS 规则自动降级”的幻想，转为组合策略：
-
正向标记优先：把
.card:not(:has(.delete-btn))改成.card默认态 +.card:has(.delete-btn)增强态。即使浏览器不支持:has()，用户看到的仍是完整默认样式，不会错乱或消失 -
服务端/构建时注入类名：在 HTML 渲染阶段判断子元素是否存在，输出
<div class="card card--has-delete">。CSS 写 <code>.card--has-delete { opacity: 0.6; }，零运行时开销，无 FOUC -
轻量 JS 补位 +
CSS.supports()守门：只对首屏关键容器执行一次判断，例如document.querySelectorAll('.card').forEach(el => { if (!el.matches(':has(.btn)')) el.classList.add('card--no-actions'); });，且用if (!CSS.supports('selector(:has(*))')) { ... }包裹，避免在已支持环境重复执行 -
必须在 DOM ready 后执行：否则
document.createElement()创建的测试元素未挂载，el.matches(':has(a)')返回false是误判，不是真实不支持 -
必须先检查 API 存在性：IE11 不支持
CSS.supports()，直接调用会报TypeError。得先写if ('supports' in CSS) { ... }，不存在就默认走降级路径 - 不能混用 @supports 块和 JS 注入样式：加载顺序不确定，CSS 解析完才执行 JS，可能导致 JS 插入的降级样式被后续 @supports 块覆盖，或反之
JS 运行时检测的两个硬性前提
想用 CSS.supports('selector(:has(a))') 做判断，必须满足两个条件，否则结果不可信：
立即学习“前端免费学习笔记（深入）”；
选择器兼容的本质不是“让旧浏览器理解新语法”，而是“不让新语法破坏旧环境的渲染”。所有方案都要围绕这个前提设计，而不是执着于某个检测 API 是否“看起来更标准”。
