@supports 规则比 js 检测更轻量可靠，专用于声明级特性检测（需带值），支持 and/or/not 逻辑但 or 必须括号包裹；它不判断浏览器版本，也不保证运行时功能可用，fallback 必须依赖基础样式。
怎么用 supports() 做浏览器特性检测并动态加样式
直接上结论：用 @supports 规则比 JS 检测更轻量、更可靠，尤其适合纯 CSS 场景下的渐进增强。它不是“能不能用某属性”，而是“当前浏览器是否真正支持该声明组合”。
常见错误是把 @supports 当成浏览器版本判断工具——比如写 @supports (display: grid) 却没考虑 IE11 虽不支持但也不报错，只是忽略整段规则；更隐蔽的是嵌套逻辑写错：@supports (not (display: grid)) and (display: flex) 实际会因括号优先级失效，变成 not ((display: grid) and (display: flex))，结果和预期相反。
- 只检测**声明（declaration）**，不是属性名本身，所以必须带值：
@supports (color: oklch(50% 0.2 120))✅，@supports (color)❌ - 支持
and/or/not，但or必须用括号包裹子条件，否则解析失败：@supports (display: grid) or (display: flex)是非法语法，得写成@supports ((display: grid) or (display: flex)) - 注意级联顺序：被
@supports包裹的规则仍受 CSS 优先级约束，别指望它能绕过 specificity
@supports 和 JS 的 CSS.supports() 选哪个
二者底层用同一引擎判断，但行为有关键差异：CSS 规则里的 @supports 在样式表解析阶段就生效，而 JS 的 CSS.supports() 是运行时调用，可传入动态拼接的字符串，但也因此可能触发 layout thrashing。
典型误用场景：在 React 组件里反复调用 CSS.supports('display: grid') 判断渲染逻辑——其实只需执行一次，且完全可用 @supports 配合 class 切换替代。
立即学习“前端免费学习笔记（深入）”；
Angel工作室企业网站管理系统全DIV+CSS模板，中英文显示，防注入sql关键字过滤，多浏览器适应，完美兼容IE6-IE8,火狐，谷歌等符合标准的浏览器，模板样式集中在一个CSS样式中，内容与样式完全分离，方便网站设计人员开发模板与管理。系统较为安全，以设计防注入，敏感字符屏蔽。新闻，产品，单页独立关键字设计，提高搜索引擎收录。内置IIS测试，双击打启动预览网站 Angel工作室企业网站
- 静态样式适配 → 无条件选
@supports规则，零 JS 开销 - 需要根据支持情况动态生成内联样式或修改 DOM 属性 → 才用
CSS.supports()，且建议缓存结果 -
CSS.supports()的参数必须是完整声明字符串，不能只传属性名，也不能省略分号：CSS.supports('display', 'grid')❌，CSS.supports('display: grid;')✅（结尾分号可选，但建议带上）
哪些 CSS 特性不适合用 @supports 检测
不是所有“新东西”都能靠它兜底。比如 container-type: inline-size 这类依赖父容器显式声明的特性，@supports (container-type: inline-size) 会返回 true，但实际布局可能完全不生效——因为检测通过只代表语法被识别，不代表环境满足运行条件。
另一个坑是自定义属性（--my-color）：你无法用 @supports 检测变量是否存在或是否有值，它只认原生属性+值对。
- 涉及运行时上下文的特性（
container、scroll-timeline、view-transition）→ 检测仅表示语法支持，不保证功能可用 - 自定义属性、
@property声明、font-palette等需配合其他声明才能生效的特性 → 单独检测意义有限 - 部分 Safari 对
@supports selector(...)支持不稳定，即使写了@supports selector(:has(...))，也可能在旧版中静默失败
兼容性底线和 fallback 设计的真实约束
别信“加了 @supports 就万事大吉”。它的 fallback 本质是“不应用这段规则”，所以你必须确保基础样式（不包裹在 @supports 里的部分）本身是可用的。很多人把所有现代写法全塞进 @supports，结果老浏览器里啥都不显示。
更麻烦的是，某些特性虽被 @supports 认为支持，但存在严重 bug：比如 Chrome 115 之前，@supports (aspect-ratio: 1/1) 返回 true，但配合 object-fit 会出错。这种只能靠具体测试，没法靠检测规避。
- 永远先写降级样式（无
@supports包裹），再在@supports里覆盖增强 - 对关键布局特性（如
grid、subgrid），建议搭配display: block等安全回退，而不是留空 - CI 中跑多浏览器截图对比比单纯查
@supports结果更有说服力
