@supports 是 css 原生特性检测机制，比 js 更早更稳地实现样式分流，避免 fouc；但无法覆盖所有特性（如 env()、container-type、自定义属性等），需 js 补位验证。
现代响应式设计已不再需要靠 JavaScript 检测设备类型或屏幕尺寸来决定样式——因为那本质上是“猜浏览器能力”，而@supports直接问浏览器“你能不能渲染这个 CSS”。
@supports 比 JS 检测更早、更稳、不闪屏
@supports 是 CSS 原生规则，浏览器在解析样式表时就执行判断，无需等待 JS 加载、执行、DOM 构建完成。这意味着：样式分流发生在首次绘制前，完全避免 FOUC（内容闪动）和布局抖动。
- JS 的
CSS.supports()必须等window.CSS可用，至少晚于<link rel="stylesheet">的 onload 事件 - @supports 规则写在
main.css里，Chrome/Firefox/Safari（17+）会在构建 CSSOM 阶段立即识别并应用或跳过整块规则 - 旧浏览器（如 IE11、Android 4.4 WebView）根本不认识
@supports，会忽略整条规则，自然回退到外层降级样式
@supports (display: grid) 不等于“支持 Grid 布局”
单测 display: grid 容易误判：Safari ≤15.4 和 Edge ≤16 虽然认这个声明，但 gap、subgrid、grid-template-areas 中的某些值实际不生效。真实项目中必须按需组合检测。
- 要用
gap？写@supports (gap: 1rem) or (grid-gap: 1rem)（兼容旧前缀） - 要用
subgrid？单独加@supports (grid-template-columns: subgrid)，它和display: grid的支持矩阵完全不同 - 要用
aspect-ratio？必须写@supports (aspect-ratio: 1/1)，不能简写成@supports aspect-ratio或漏括号
@supports 无法检测的特性，JS 层必须主动验证
有些特性 @supports 根本不支持语法检测，或者检测结果与实际渲染不符，这时只能靠 JS 动态写入 + 读取验证。
-
env(safe-area-inset-top)：必须写@supports (padding-top: env(safe-area-inset-top))，不能省略属性名 -
container-type：Firefox 106 之前完全不识别该语法，@supports not分支也不会触发 → 得用ResizeObserver监听容器尺寸变化后动态加类 - 自定义属性（
--color）、scroll()时间函数、contain：@supports 无效 → JS 中创建临时元素，设style.setProperty('--test', 'red')，再用getComputedStyle(el).getPropertyValue('--test')读回确认
逻辑运算符写错会让整块规则静默失效
@supports 条件语法极其严格：一个空格、一个括号、一个大小写错误，都会导致浏览器丢弃整个规则块（包括花括号内所有样式），而不是只跳过条件。
- 正确：
@supports (display: flex) and (inset-inline-start: 0)（and小写，前后各一空格） - 错误：
@supports (display:flex)AND(inset-inline-start:0)（无空格、大写 AND）→ 整块被忽略 - 错误：
@supports (--primary: #007bff)（自定义属性检测在 Safari ≤13.1 中不可靠，且部分版本语法报错）→ 推荐改用 JS 层检测后给加no-cssvars类 - 嵌套 @supports（如
@supports (...) { @supports (...) { ... } }）目前仅 Chrome ≥110 / Firefox ≥109 支持，Safari 仍不支持 → 生产环境禁用
真正关键的不是“能不能写 @supports”，而是理解它在哪一层生效、哪些能力它根本管不了、以及 JS 层该补哪一块——否则很容易写出看似优雅、实则在 Safari 16.4 或 Firefox 105 上完全不工作的降级逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
