根本原因是@supports检测逻辑写反了——它不是条件编译开关，而是“若支持某特性则启用对应样式”，应将现代样式放入@supports块内，降级方案写在外部。
为什么 @supports 检测后样式还是不生效
根本原因常是检测逻辑写反了——@supports 里写的不是“浏览器支持什么”，而是“**如果支持某特性，就启用对应样式**”。很多人误把它当条件编译开关，结果把降级样式塞进了支持块里。
典型错误写法：
@supports (display: grid) {
.container { display: grid; }
.fallback { display: none; } /* 错！这里不该隐藏降级方案 */
}
- 正确思路：把现代样式放
@supports块内，把兼容方案（如float/inline-block）写在外部，让不支持的浏览器自然回退 - 注意语法细节：
@supports not (display: grid)中的not必须紧贴括号，空格或换行会直接导致整条规则失效 - 某些旧版 Safari（≤12.1）对嵌套
@supports或复合条件（如and/or）解析不稳定，建议单条件检测、分块书写
哪些 CSS 特性值得用 @supports 检测
不是所有新特性都适合检测。优先覆盖那些「有明确替代方案 + 浏览器支持断层明显」的属性。
-
display: grid和display: subgrid：IE 完全不支持，iOS Safari 10.3+ 才支持基础 Grid，检测后可 fallback 到flexbox或float -
aspect-ratio：Chrome 88+、Firefox 89+ 支持，此前只能靠 padding-top 技巧，检测后可简化布局代码 -
color-mix()、color-contrast()等 CSS Color 4 函数：目前仅 Chrome 111+ 实验性支持，检测意义大于实用，慎用 - 避免检测
gap单独存在——它依赖display: flex或grid上下文，单独检测无意义，应和容器显示模式一起判断
@supports 与 JavaScript 检测混用时的坑
JS 里调用 CSS.supports() 和 CSS 中的 @supports 规则不是完全等价的。前者是运行时查询，后者是声明式解析，两者触发时机和上下文不同。
- CSS 的
@supports在样式表解析阶段就决定是否应用规则；而 JS 的CSS.supports('display', 'grid')返回布尔值，但无法动态插入已解析的 CSS 规则 - 不要在 JS 中根据
CSS.supports()结果去document.styleSheets[0].insertRule()注入@supports块——多数浏览器会忽略这种动态插入的特性检测规则 - 真要动态控制，不如用 JS 切换 class：
document.body.classList.add('supports-grid')，再写.supports-grid .container { display: grid; } - 注意 SSR 场景：服务端无法执行
CSS.supports()，若依赖 JS 检测做首屏渲染，可能造成水合 mismatch
移动端 WebView 兼容性比想象中更碎
Android WebView 和 iOS WKWebView 的 CSS 支持版本并不严格跟随系统浏览器。比如 Android 10 的 WebView 可能基于 Chromium 75，但部分厂商（华为、小米）会定制内核，导致 @supports (inset: 0) 这类新特性返回 true 却实际不工作。
- 测试时别只看 Chrome for Android，务必在目标机型自带浏览器中实机验证
- 对关键布局（如弹窗居中、安全区适配），建议双重保险：先用
@supports检测，再加一层 JS 尺寸校验（如getComputedStyle(el).display === 'grid'） -
@supports selector(:has(...))这类选择器检测目前仅 Chrome 105+ / Safari 15.4+ 支持，且 Safari 需开启实验性功能，生产环境慎用
真正麻烦的从来不是写检测，而是得同时盯着 CanIUse 数据、各厂商 WebView 更新节奏、以及用户实际设备上报的 UA 字符串里藏了多少个“Chrome/0.0”伪装项。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
