@supports 是 CSS 原生功能检测机制，为声明式条件规则容器，不触发重排重绘；与 JS 检测相比，它仅在解析时生效、不可动态响应，但更轻量、纯 CSS 驱动。
什么是 @supports，它和 JavaScript 检测有什么区别？
@supports 是 CSS 原生的功能检测机制，不是“选择器”，而是一个条件规则容器——它根据浏览器是否支持某项 CSS 特性，决定是否应用内部的样式块。它不依赖 JS 执行，也不触发重排/重绘，纯声明式，适合做渐进增强。
和 JS 的 CSS.supports() 不同：@supports 只在样式表解析阶段生效，无法动态响应运行时变化；而 JS 检测可结合事件或 DOM 变化重新判断，但需要手动插入样式或切换 class。
常见误用是把它当“浏览器版本判断”用——比如写 @supports (display: grid) 来代替 IE 兜底，这没问题；但写 @supports (-webkit-appearance: none) 试图区分 Safari 和 Chrome 就不可靠，因为两者都支持，只是行为细节不同。
@supports 语法怎么写才不会被忽略？
必须用完整、合法的 CSS 声明（property: value 形式）作为条件，括号不能省，冒号前后可有空格，但值不能带单位缩写歧义（如 width: 50 会被当成无效声明而整个规则失效）。
立即学习“前端免费学习笔记（深入）”；
@supports (display: grid) {
.container { display: grid; }
}
@supports (not (aspect-ratio: 1/1)) {
.box { width: 200px; height: 200px; }
}注意三点：
-
not必须包在括号里，写成@supports not (display: grid)是语法错误 - 多条件用
and/or连接，and优先级高于or，复杂逻辑建议嵌套括号 - 浏览器遇到无法识别的属性或值（如
color: lab(50% 0.2 0.1)在旧版 Safari），会直接跳过整个@supports块，不报错也不回退
哪些特性检测容易踩坑？
aspect-ratio、inset、scrollbar-gutter 等较新特性，在部分 Chromium 版本中支持但需开启 flag，或仅支持带前缀的旧语法（如 -webkit-aspect-ratio），此时 @supports (aspect-ratio: 1/1) 会返回 false。
contain: paint 在 Firefox 中长期不支持，但 @supports (contain: paint) 却可能返回 true（因解析到 contain 属性本身存在，而非具体值）——这是规范陷阱：@supports 检测的是“声明是否被识别并接受”，不是“是否按预期渲染”。
实际建议：
- 对关键布局特性（如
grid/flex），优先用@supports (display: grid)，比检测子属性更稳妥 - 检测函数类语法（如
color-mix()、cross-fade()）时，必须写完整调用形式：@supports (background: color-mix(in srgb, red, blue)) - 避免检测尚未进入正式标准的实验性语法（如
view-transition-name），即使当前能用，也可能随规范变动失效
和 @media 混用时顺序和作用域要注意什么？
@supports 和 @media 可以嵌套，但顺序影响结果。浏览器先解析外层规则，再判断内层条件。例如：
@media (min-width: 768px) {
@supports (display: grid) {
.layout { display: grid; }
}
}这表示“仅在宽屏且支持 grid 时启用 grid 布局”。但如果反过来：
@supports (display: grid) {
@media (min-width: 768px) {
.layout { display: grid; }
}
}语义相同，但某些旧版 Edge（≤18）会忽略内层 @media，导致规则完全不生效。
更隐蔽的问题是作用域：嵌套规则里的选择器仍受全局 CSS 层叠影响，@supports 块内写的 .btn { padding: 1em } 并不会只在支持条件下覆盖外部同名规则——它只是“有条件地插入这条样式”，和其他样式一样参与层叠计算。
真正要控制降级，得靠明确的优先级设计，比如给不支持的场景加 class：html.no-grid .container，再用 JS 检测后添加 class，而不是只靠 @supports 孤立作战。
@supports 最适合做轻量级样式增强，别指望它解决所有兼容性问题；它的价值在于让 CSS 自己说话，而不是替代 JS 或构建复杂的 polyfill 流程。
