@supports 语法错误会导致整个规则块被忽略；需注意函数支持性、属性名拼写、值不加引号、逻辑运算符小写及空格、避免嵌套、推荐@media包裹@supports、JS检测存在兼容偏差。
@supports 语法写错会导致整个规则块被忽略
浏览器遇到无法解析的 @supports 条件时，会直接丢弃整条规则（包括花括号内的所有声明），而不是跳过条件只执行样式。常见错误是用了不支持的函数、拼错属性名，或在条件里写了值但没加引号（比如 @supports (display: grid) 是对的，但 @supports (display: "grid") 就错——值不能加引号）。
- 条件中只能用标准 CSS 属性和值，不支持自定义属性（
--foo）或 JS 表达式 - 逻辑运算符
and/or/not必须小写，且前后各需一个空格，not (display: flex)合法，NOT(display:flex)不合法 - 检测多值属性（如
background）要谨慎：浏览器可能部分支持（比如支持渐变但不支持paint()），建议拆成原子属性检测，例如优先用background-color或background-image
检测 Grid 布局兼容性别只看 display: 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的支持度完全不同 - 避免嵌套
@supports：浏览器对嵌套支持不一，Chrome ≥110 支持，Firefox ≥109 才支持，Safari 目前仍不支持嵌套
@supports 和媒体查询混用时的执行顺序很关键
@supports 是 CSS 规则级条件，媒体查询是容器级条件，两者嵌套时，浏览器先解析外层，再判断内层是否生效。如果把 @supports 写在 @media 外面，那么即使媒体查询不匹配，浏览器仍会尝试解析 @supports 条件——这本身没问题；但如果反过来，把 @media 套在 @supports 里面，就可能因支持度问题导致整块失效。
- 推荐结构：总是
@media包裹@supports，即@media (min-width: 768px) { @supports (display: grid) { ... } } - 不要写
@supports (...) { @media (...) { ... } }，IE 和部分老 Android 浏览器会直接跳过内部媒体查询 - 注意：CSS 加载是异步的，
@supports检测基于当前 CSSOM 状态，无法感知后续动态注入的样式表
JavaScript 动态检测不如 @supports 精准，但能补足边界场景
CSS @supports 检测的是渲染引擎原生能力，而 JS 的 CSS.supports() 虽然 API 一致，但部分浏览器（如 Safari ≤15.6）对复杂条件（含 not 或括号嵌套）返回 false 即使实际支持。反过来，有些属性 JS 能查到但 CSS 无法启用（比如受限于当前元素状态）。
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染或构建时做静态降级？用 PostCSS 插件（如
postcss-supports）比 JS 更可靠 - 需要运行时响应式切换？优先用
CSS.supports('display', 'grid')，但避开CSS.supports('(display: grid) and (gap: 1rem)')这类复合字符串形式 - 真正难搞的是「部分支持」：比如 Firefox 支持
contain: paint但不支持contain: strict，此时@supports (contain: paint)为真，但业务逻辑仍可能出错——得靠具体属性值测试
aspect-ratio 这种分阶段实现的特性，每个浏览器都卡在不同环节。 
