@supports 是浏览器原生 CSS 条件规则，检测渲染引擎是否支持某特性并能正确解析应用；必须用括号包裹完整声明对（如 (display: grid)），支持嵌套但不支持逻辑简写，不可在其中使用 @import。
如何用 @supports 检测 CSS 特性是否可用
@supports 是浏览器原生支持的 CSS 条件规则，它不是 JavaScript，也不依赖运行时脚本——只要浏览器解析到这条规则，就会立即根据当前引擎能力判断真假。它检测的是「渲染引擎是否实现了该特性并能正确解析和应用」，而不是「有没有开启实验性标志」或「用户是否禁用了某功能」。
常见误用是把它当 JS 的 if 用，写成 @supports (display: grid) { ... } 却忘了加括号包裹声明；正确写法必须是 @supports (display: grid) 或 @supports not (selector(:has())) ——括号里是一个完整的声明对（property: value），不能只写属性名。
- 支持嵌套：可在
@supports块内再写@media或另一个@supports - 不支持逻辑简写：不能写
@supports (display: grid) and (inset: 0)，必须用and连接完整条件 - 注意空格：
@supports ( backdrop-filter: blur(1px) )中的空格不影响，但括号必须紧贴条件，不能写成@supports( ... )
怎样配合 @import 实现按需加载 CSS 文件
CSS 本身不支持在 @supports 里直接 @import 外部文件——这是语法错误。@import 只能在样式表顶层或 @layer 内使用，不能放在 @supports、@media 等条件块中。
真正可行的方式是：把新特性相关样式单独抽成一个 CSS 文件，然后在 HTML 中用 <link rel="stylesheet" href="modern.css" media="not all"> 预加载，再通过 @supports 触发媒体查询切换：
立即学习“前端免费学习笔记（深入）”；
<link rel="stylesheet" href="modern.css" media="not all">
<style>
@supports (display: grid) {
link[rel="stylesheet"][href="modern.css"] {
/* 无效：CSS 无法操作 link 标签 */
}
}
</style>所以实际做法只能是：把 @supports 块写在主样式表里，把现代样式内联进去；或者用 JS 检测后动态设置 link.media = "all"。后者更可控，但会多一次请求——如果只是小范围增强（比如按钮动效、阴影优化），直接内联更稳妥。
为什么 @supports 有时返回 false，但 DevTools 里手动加样式却生效
典型场景：你在 Chrome 120+ 测试 @supports (color-scheme: dark)，结果没进块，但打开 DevTools 手动加 color-scheme: dark 到 <html> 就立刻变暗了。
这是因为 @supports 检测的是「该声明能否被声明所在上下文合法接受」，而 color-scheme 只允许出现在 <html> 或 :root，若你把它写在 .card { @supports (color-scheme: dark) { ... } } 里，整个条件就失效——浏览器认为这个声明在此处语法非法，直接判为不支持。
- 检查声明位置：确保待测特性允许出现在当前选择器作用域（例如
contain必须用于布局容器元素） - 避免拼写错误：
@supports (font-optical-sizing: auto)在 Safari 16.4+ 才支持，旧版返回 false 是正常行为 - 不要混用实验前缀：
@supports (-webkit-backdrop-filter: blur(1px))是有效的，但标准写法应优先用无前缀版本
渐进增强时最容易忽略的兼容断点
渐进增强不是“有就用，没有就降级”，而是要明确「降级后是否仍可交互、可读、可访问」。比如用 @supports (inset: 0) 替换 top/right/bottom/left，但如果父容器没设 position: relative，降级后的老写法照样失效。
另一个盲区是伪类组合：@supports selector(:has(> .active)) 虽然能检测，但一旦启用，就得同步保证所有匹配逻辑在 JS 和语义结构上也兼容——否则视觉上“看起来对了”，实际焦点管理或屏幕阅读器行为可能出错。
真正关键的不是“能不能用新语法”，而是“用了之后，老浏览器用户是否还能完成核心任务”。这往往需要在 @supports 块外保留一套经过测试的兜底样式，而不是指望自动 fallback。
